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ABSTRACT 



DUDLEY KNOX LIBRARY 

naval postgraduate school 

MONTEREY CA 93943-5101 



Any military operation, no matter how large or small requires some level of 
planning. Planning has become more complicated, requiring more interactions across 
geographical, functional, and organizational boundaries in a more compressed 
command and control decision cycle. For ships at sea, conducting planning with 
other units, at sea or on shore, is constrained by the availability of communications 
bandwidth and limitations of the tools used for real-time interactions. Emerging tools 
such as audio and video conferencing and shared whiteboard, enable real time 
collaboration among dispersed forces, however, these tools are bandwidth “greedy,” 
requiring more than is currently available on many ships. In an effort to determine 
what amount of bandwidth a ship needs, this thesis used simulation and modeling to 
experiment with combinations of bandwidth, collaboration tools and the number of 
planners. 

In general, a bandwidth of 128 kbps enables two ships to conduct a video and 
audio session. Using multicast network delivery, 256 kbps enables a ship to 
collaborate with five other sites, and at 384 kbps, a ship can conduct a whiteboard 
with video and audio with up to eight other sites. 
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EXECUTIVE SUMMARY 



Planning is the act of preparing for future events. Any military operation, no 
matter how large or small, length of anticipated duration, or how much time is 
available to prepare, requires some level of planning. In today’s environment of 
increased operational tempo, more widely dispersed forces, and operations in joint or 
multinational coalition force structures, planning has become more complicated. 
Planning requires more interactions across geographical, functional, and 
organizational boundaries and in a more compressed timeframe in order to keep our 
command and control decision cycle faster than our adversaries. For ships at sea, 
conducting planning with other units, at sea or on shore, is constrained by the 
availability of communications bandwidth and limitations of the tools used for real- 
time interactions. 

Emerging products, such as audio and desktop video conferencing, and shared 
whiteboard, enable geographically dispersed people to collaborate in real-time. Used 
at sea, these tools provide the ability for planners to share information in a wide 
variety of formats, in real-time with their counterparts on other ships or ashore. 
However, these tools are bandwidth “greedy” and require more bandwidth than is 
currently available on many ships. Any implementation of these tools involves a 
trade-off decision between the cost of the resource, bandwidth, and the amount of 
capability desired, such as audio, video, or whiteboard. 

How much bandwidth does an amphibious ship need in order to perform 
collaborative planning? The thesis seeks to provide some insight into this question 
through the use of a high-level simulation model built using a commercial off-the-shelf 
product called Extend. Over 170 model runs were executed with various 
combinations of the three collaboration tool types, the amount of bandwidth, the 
number of planners involved in a planning session, and the type of network delivery 
method used. The results of these runs are presented from three different aspects, by 
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required collaboration capabilities, by bandwidth, or by the number of other planners 
that can be involved, as follows: 

• Minimum collaboration capabilty required by the ship. If, at a minimum, a ship 
must be able to conduct a video and audio session with one other ship, than at 
least 128 kbps must be available to each ship. To conduct a whiteboard with 
audio session, at least 256 kbps must be available. Whiteboard with video and 
audio requires 384 kbps. 

• Bandwidth is limited. If a ship only has 128 kbps available, then the ship will only 
be able to conduct a video and audio session with one other ship. At 256 kbps, a 
ship can collaborate via a video and audio session or a whiteboard with audio 
session with up to two other sites. At 384 kbps, using multicast delivery, a ship 
will be able to engage up to eight other sites in a whiteboard with audio session. 

• Number of planners required in a collaboration session. To collaborate with one 
other planner a ship requires at least 128 kbps and a session with two other 
planners, at least 256 kbps. To collaborate with five to eight other planners, at 
least 384 kbps must be available at the ship and multicast network delivery must 
be used to ease the bandwidth congestion at the ship. 

To ensure flexibility and adaptability to any planning situations a ship may be 
engaged in, an optimum mix might be to provide at least 256 kbps bandwidth and use 
multicast network delivery, so the ship can access some combination of the three 
collaboration capabilities provided by the tools with up to five planning counterparts. 
Without multicast delivery, at least 384 kbps will be required for three ships to engage 
in a collaborative planning. 
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I. INTRODUCTION 



A. OVERVIEW 

An amphibious operation is an attack launched from the sea by naval and landing 
forces embarked in ships or craft landing on a hostile shore (Joint Pub 3-02). The amount 
of communications support required for such an operation exceeds that of any type of 
naval warfare (Kim and Muehldorf). Planning for a landing is also complex due to the 
involvement of all types of ships, aircraft, weapons, and units of the Navy and landing 
forces and the geographic dispersion of supporting forces. 

Much of the information shared and analyzed during amphibious landing planning 
involves the use of maps, charts, and imagery. Ships are limited in the ways they can 
interact with their planning partners at sea or ashore, and the format of the information 
does not lend itself to unambiguous discussion over voice circuits or through text 
messages. Planners left to work independently in different locations on the same plan run 
the risk of forming separate and distinct interpretations of that plan unless efforts are 
expended to keep all planners in synchrony. 

New communications capabilities are possible with the use of collaboration tools such 
as audio and video conferencing and whiteboard applications. These tools can provide the 
means for an Amphibious Ready Group (ARG) or Amphibious Task Force (ATF) at sea 
to continue to conduct planning with shore-based or other ship organizations and to do it 
in real-time. However, these tools require higher bandwidths than currently possessed by 
amphibious ships. SHF bandwidth to the ARG Flagship (LHA/LPD) can range from 256 
kbps to 512 kbps, but the other ARG ships are not SHF-capable. All amphibious ships are 
UHF-capable, which can range from 2.4 kbps to 9.6 kbps. 

Several efforts are underway to increase the amount of bandwidth on these ships, and 
most are focused on point-to-point or Line of Sight communications for use between two 
ships or a ship and shore-based unit. Three efforts of note are (CPG3, Day): 
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• Digital Wideband Transmission System (DWTS) which will provide UHF LOS 
at T1 (1.544 Mbps) from ship to ship and from ship to shore at 144 kbps, 288 
kbps or 576 kbps. 

• UHF Medium Data Rate (MDR) which will provide 448 kbps. 

• Hazeltine, an effort to provide a “network” capability among three ships using 
radios at 64 kbps. 



B. OBJECTIVE 

The purpose of this thesis is to determine the bandwidth requirements for collaborative 
planning by amphibious ships. The approach taken was to identify characteristics of the 
tools used for collaboration (text chat, audio and video conferencing, whiteboard) and 
simulate the use of these tools in a network among two to nine planning participants, 
varying the amount of available bandwidth. 



C. METHODOLOGY 

To assess the impact that bandwidth has on the use of collaboration tools, a network 
simulation model was built using Extend, by Imagine That, Inc. To derive the parameters 
of the model, current information about collaboration tools, their bandwidth requirements 
and the planning process employed by Amphibious Ready Groups (ARG) was obtained by 
conducting a literature review, Internet searches, and discussions with personnel at 
SPAWAR San Diego, COMPHIBGRU THREE, Amphibious Warfare School Pacific, and 
MITRE. Various combinations of the parameter settings were executed and the model 
results were assessed against the following selected measures of effectiveness: the average 
amount of time for text chat, audio, video and whiteboard data to travel between 
participants. Lengthy travel times degrade the quality of audio and video conferencing. 
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D. THESIS ORGANIZATION 



Chapter II provides an overview of four collaboration tools, text chat, audio 
conferencing, video conferencing, and whiteboard, with discussion of their limitations and 
bandwidth requirements. Chapter HI presents background on the ARG planning process, 
such as what information is discussed and when, who is involved, and where planning 
occurs. A discussion of the Extend model structure and specific parameter settings are 
contained in Chapter IV, and the results of the model runs are presented in Chapter V. 
Chapter VI will provide conclusions and recommendations for future work. 
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n. COLLABORATION TOOLS 



A. OVERVIEW 

Collaboration tools began to emerge in the early 1990’s when faster PCs, increased 
network and communications bandwidth, and more-capable digital video components 
brought such capabilities into the realm of possibility and affordability (Garland). This 
chapter will highlight a few collaboration tools that provide the means for same-time, 
different-place interactions such as text chat, audio conferencing, whiteboard, and desktop 
video conferencing. Short descriptions of each tool, applicable standards, general 
limitations, and the bandwidth required will be presented. The intent is not to elaborate on 
all the technical details associated with multimedia products and processes but to give a 
feel for some of the concepts and issues. 



B. DEFINITIONS 

The following definitions and concepts are common across all collaboration tools and 
impact how the tools are implemented. 

L Collaboration 

The Random House Unabridged Dictionary, Second Edition, 1993, defines 
collaboration “to work, one with another; cooperate.” Cooperate is “to work or act 
together or jointly for a common purpose or benefit.” Collaboration always involves some 
form of interaction between two or more people and it can occur at any time or at any 
place. “People who need to collaborate can be in the same team or unit, different parts of 
an organization, and in different organizations. They can be located anywhere on the 
globe and in any time zone, but still require the ability to communicate with each other, 
share information with each other, and coordinate their activities” (DIICOE MCSTWG). 
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2. Multimedia 



As defined in the Dictionary of PC Hardware and Data Communications Terms, by 
O’Reilly and Associates, 1996, multimedia means “Literally ‘many media’, for example, 
using sound, pictures, and text to (hopefully) make a more effective, understandable, or 
memorable presentation or conference.” 

Multimedia teleconferencing is a combination of technology and applications that 
allow multiple users in multiple locations to interactively share data, desktop applications, 
and live video simultaneously. The ability to share materials facilitates communications, 
brainstorming, decision making, and problem solving. (EMTC) 

To support multimedia, networks must provide (O’Reilly): 

• Scalable bandwidth: New users and new applications require connectivity and 
the network must support ever-increasing traffic loads. 

• Consistent Quality of Service: The error rate (usually due to dropped packets), 
network latency (typically less than 400 ms, round-trip), and network 
throughput must be selectable (according to the needs of the application) and 
predictable. 

• Multicast routing, to efficiently support one-to-many-type traffic. 



3. Bandwidth 

In general terms, bandwidth has come to mean the number of bits per second (bps) 
that can be transmitted over various media and is the most significant limiting factor in 
communications. There are two broad categories of communication channels, circuit- 
switched and packet-switched, and each has implications for multimedia teleconferencing. 
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Circuit-switched means that a dedicated path is formed between users and all of 
the available bandwidth of that channel is for their use only; it is not shared with other 
users. Collaboration tools get the bandwidth they require and the delivery of information 
is predictable, without delays. If the full amount of the dedicated bandwidth is not needed 
during the connection, it is in effect “wasted” since there are no other activities on the 
circuit to use it. When the communications are complete, the dedicated channel is 
disestablished and the bandwidth is then available for other sessions. Circuit-switched 
channels are primarily for point to point communications, and conducting a collaborative 
session with greater than two sites requires the use of expensive Multipoint Conference 
Units (MCU). An MCU is a server that establishes and manages real-time distribution of 
audio, video, and document sharing among several sites. Examples of circuit-switched 
channels are the telephone system and narrowband Integrated Services Digital Network 
(ISDN) at 128 Kbps. 

Packet-switched channels share their total bandwidth among all the users who 
want to use it. A user’s information is broken into packets and each is labeled with 
identification, sequence number, and destination. The packets are placed onto a channel 
and may take differing routes through the network to reach their destination, some 
arriving earlier than others. The time required for the transit depends upon the number of 
users on the channel - more users means more packets competing for a finite amount of 
bandwidth resulting in longer delays. Collaboration tools such as audio and video are 
sensitive to packets that arrive out of order or experience lengthy delays in arrivals. 
Examples of packet-switched channels are Local Area Networks, such as 10 Mbps to 100 
Mbps Ethernet, and Wide Area Networks, such as Asynchronous Transfer Mode (ATM) 
at 25 Mbps to 2 Gbps and Frame Relay at 56 Kbps to 1 .544 Mbps. 

To cope with bandwidth limitations, many collaboration applications provide the 
ability for users to adjust several parameters of their audio and video sessions. 
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4. Compression and Decompression (Codec) 

The nature of audio or video data is such that it requires large amounts of bits for 
accurate representation. To conserve the amount of bandwidth used when sending audio 
or video data, the bits that represent the data are compressed into an even smaller number 
of bits before transmission using complex algorithms called Codecs. At the receiving end, 
the bits are decompressed and reconstructed to the original form. 

Compression and decompression must occur at extremely fast speeds so as not to 
interfere with the real time interaction of a collaborative session. Hardware Codecs are 
extremely fast at performing compression algorithms, but they are also very expensive. 
Software Codecs are easier to install and rely on the workstation CPU for processing 
power, not additional hardware. The strain the software Codec puts on the CPU may 
limit the number or type of applications a user may execute simultaneously during a 
session. Some Codec implementations are a mix of hardware and software - hardware for 
compression, which is more computationally intense and needs to be done quickly without 
introducing delay and software for decompression. (CISCO, Hudson) 

Many algorithms have been developed for implementing compression but generally 
these schemes fall into one of two types (CISCO): 



• Lossless. A compression technique that creates compressed files that 
decompress into exactly the same file as the original. Lossless compression is 
typically used for executables (applications) and data files for which any 
change in digital makeup renders the file useless. 

• Lossy. This type of compression, used primarily on still image and video 
image files, creates compressed files that decompress into images that look 
similar to the original but are different in digital makeup. The “loss” is that 
several bits of the image are no longer represented but the human eye does not 
detect this loss. 



8 



Interoperability issues frequently arise between collaboration products since many 
vendors have developed their own proprietary Codec algorithms, which offer a wide range 
of performance, quality, and cost trade-offs. 

5. Latency 

Real time interactive applications are sensitive to accumulated delay, known as 
latency. A network contributes to latency in the following ways (CISCO): 

• Propagation Delay. The length of time that information takes to travel the 
distance of the line. Propagation delay is determined by the speed of light and 
is not affected by the networking technology in use. 

• Transmission Delay. The length of time a packet takes to cross a given media. 
Determined by the speed of the media and the size of the packet. 

• Store and Forward Delay. The length of time an internetworking device (a 
switch, bridge, or router) takes to send a packet that it has received. 

• Processing Delay. The time required by an internetworking device to perform 
a route lookup, change headers, and other switching tasks. In some cases, the 
packet may have to be manipulated such as encapsulating it into another packet 
type. 

Variable network delays can cause disruptions in audio or video data, called 
“jitter.” A common technique for minimizing jitter is to buffer the arriving data at the 
receiving end and then deliver it to the user at a more constant rate. 
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6. Quality of Service 

Two measures of quality of service are the reliability of delivery across a network 
and the amount of delay experienced. Different types of data have varying degrees of 
sensitivity to these measures. For example, transferring data files requires more emphasis 
on reliable delivery than on minimizing delays encountered during the transfer. It is more 
important that all the bits arrive than whether the file arrives within one second or one 
minute at its destination. Table 2-1 summarizes data types and their sensitivity to reliable 
delivery and delay. 





Data 


Voice 


Video 


Image 


Delay Sensitive 


No 


Yes 


Yes 


No 


Reliability Sensitive 


Yes 


No 


Yes/No 


Yes 



Table 2-1. Data Type Sensitivities (Rettinger). 



Delays in voice transmissions can be annoying and frustrating to people involved 
in a discussion, as it is disruptive to the flow. Studies have shown that people get annoyed 
when end-to-end audio delays approach 400 milliseconds (ms) and 700 ms to 800 ms is 
beyond tolerance. Ideal quality of service for a one-way audio stream is considered to be 
less than 45 ms delay plus variance. Telephone networks are engineered to provide less 
than 400 milliseconds round-trip latency for the voice signals they handle. Voice is not 
sensitive to reliability and the occasional missing sounds or syllables can be recovered by 
the speaker repeating them or deduced by the receiver based upon content. (Brown, 
Rettinger) 

Delays in receiving video can cause movements to appear jumpy. Uncompressed 
video is more tolerant of lower reliability because the video is transmitted a frame at a time 
and any frame sent with an error or lost enroute will be replaced by a newly arriving 
frame. Compressed video is already reduced in the amount of data it contains, so any 
corruption or loss may not be corrected by subsequent frame updates as the redundancy 
has been removed. This possibility is corrected by sending out refresh updates - a series 
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of frames that contain all the video data. Tolerable delay for video can be up to 95 ms 
delay plus variance. (Brown, Rettinger) 

If given a choice in a collaboration session as to whether to experience audio 
delay or video delay, most people prefer the audio to be delivered as close to real time as 
possible and will endure a delay in the video even though it will be out of sync with the 
audio (Isaacs). 

7. Standards 

To guide the development of collaboration tools that are interoperable, there are 
several standards which have been ratified by the International Telecommunications Union 
(ITU). The T.120 series addresses real time data conferencing (audiographics) standards 
that allow people at multiple locations to conduct normal voice conferences and 
manipulate still images such as documents, spreadsheets, color graphics, and photographs. 
(IMTC) 

The H.320 series governs the basic concepts of audio, video, and graphical 
communications by specifying requirements for processing audio and video information, 
providing common formats for inputs and outputs, and protocols for use of 
communications links and synchronization of signals. Specifically, H.320 standards 
address videoconferencing over circuit switched networks, such as Integrated Services 
Digital Network (ISDN). H.323 extends H.320 video to corporate Intranets, LANs and 
other packet-switched networks, such as the Internet. H.324 specifies a common method 
for sharing video, data, and voice simultaneously using high-speed modem connections 
over a single analog line telephone line. (IMTC) 

Since collaboration implies communications with others, using products that 
support these standards is the single biggest factor towards being able to conduct 
interoperable collaboration sessions. All parties conducting a collaboration session must 
use products that support the same standards or the session can not be conducted. 
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C. TEXT CHAT 



1. Description 

Text chat is a method by which two or more people can converse in real time by 
typing their comments on their computers, which are connected via a network. Each 
person sees the comments typed by the other conversation participants. What you type is 
what they see. Conversations can be held between two people or up to several hundred 
people. 

Users execute text chat via a client program running on their PC’s, and designated 
computers on the network run server programs. These servers help manage and transport 
the messages between clients. Each conversation is called a channel and they may be 
public (where everyone in a channel can see what you type) or private (messages between 
only two people, who may or may not be on the same channel). The number of members 
participating in a channel is dynamic - users may join and leave at any time. A channel 
may also be thought of as a named group of one or more users, which will all receive 
messages addressed to that channel. 



2. Standards 

The most common program for text chat is Internet Relay Chat (IRC), which has 
been around since the late 1980s and is available for download from several Internet sites 
for several platforms: UNIX, Windows, and Macintosh. IRC consists of various separate 
networks (or "nets") of IRC servers that allow users to connect to IRC. One of the 
largest nets is Efhet, the original IRC net, which often has more than 32,000 people 
participating at once and has more than 12,000 channels, each devoted to a different topic 
[IRC], Internet Relay Chat is the Internet Engineering Task Force (IETF) standard for 
text-based chat (MITRE). 
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3. Limitations 



People can think and talk faster than they can type, so lengthy, meaningful 
conversations can be difficult to conduct online. There is a maximum user message length 
of 512 characters (about seven typed lines) so most conversations consist of short 
comments and requests for information (IRC). Obviously this tool is better suited to share 
text-based information, not graphics or imagery. Text chat is a good tool for 

communications across a network when other tools are not available, such as the 
telephone, video or audio conferencing, or in situations when bandwidth is constrained. 



4. Bandwidth Requirements 

Of all the collaboration tools, text chat requires the least amount of bandwidth. 
Messages have a maximum size of 512 characters or, at 8 bits per character, a total of 
4096 bits. Increasing the number of participants in a text chat session does not really 
degrade the network too much since the amount of information sent at a time is so small 
and not usually sent all at the same time. For example, if three people were in a text chat 
session, the worst case scenario would be everyone sending a message at the same time. 
A user sending out 4096 bits while receiving 8192 bits from the other two people (4096 
bits each) would have a total of 12,288 bits competing for bandwidth at her workstation. 



D. AUDIO CONFERENCING 
1. Description 

Audio conferencing has traditionally been conducted using the telephone system 
for performing person-to-person calls or conference calls of greater than 2 people. Audio 
conferences can be performed across networks with the addition of a microphone, 
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speakers, a sound card, and a compression-decompression (Codec) algorithm to a 
personal computer. 

The overall process is to digitize your voice’s analog signals, compress the digital 
form, transmit it, then decompress and decode the digital signal at the receiving end - all in 
real time. Analog to digital conversion basically consists of taking a series of samples of 
the analog source and representing those samples with a number of bits. The higher the 
sampling rate and the higher the number of representative bits, the higher the quality of the 
digitized audio because more information will be available to recreate the original analog 
source. Some common sampling rates are: 8000 samples per second at eight bits per 
sample, for telephone quality audio, and 44000 samples per second at 16 bits per sample, 
for CD quality. 



2. Standards 

There are several Codecs recommended by the ITU and other public standards 
listed in Table 2-2. Minimum compliance is to employ G.71 1 . 



Codec 


Data Rate 


Comments 


G.711 


48, 56, 64 Kbps 


(Narrowband) Telephone quality audio. 


G.722 


48, 56, 64 Kbps 


(Wideband) Stereo quality audio. 


G.723.1 


5.3 and 6.4 Kbps 


Speech Coding at very low rates. 


G.728 


16 Kbps 


Optionally lower rate for use in video conferences with 
limited bandwidth. 


G.729 


8 Kbps 




GSM 


17 Kbps 


(Group Speciale Mobile) European Standard for 
Cellular Telephony. 


LPC-10 


2.4 kbps 


U.S. Federal Standard 


CELP 


4.8 kbps 


(Code Excited Linear Prediction) U. S. Federal 
Standard 



Table 2-2. Audio Codecs (MITRE). 
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3. Limitations 



Audio signals are sensitive to network delays as described earlier. Audio 
conferencing over a network is typically not done in stand-alone mode. It is usually 
bundled with whiteboard or video conferencing tools to enable amplifying information to 
be discussed along with the presentations shown on the computer screen. If all you are 
going to do is talk, you might as well use the phone; it is easy, cheap, and interoperable. 



4. Bandwidth Requirements 

Most commonly used measure for audio is a minimum rate of 64 Kbps, based on 
telephone quality at 8000 samples a second, 8 bits a sample. For CD quality sound, at 
44000 samples every second and 16 bits per sample, a “worst case” data rate of 704 Kbps 
would be required. 

Compression can be used to lower these data rates as well as the mode of 
operation. Full duplex mode of audio is being able to hear and speak at the same time. 
This uses up more bandwidth since in effect you will have two streams, one in and one 
out. Half-duplex mode, in which audio occurs in one direction at a time triggered by the 
person who is speaking, is bandwidth conservative. 

As an example, two people conducting an audio conference with telephone quality 
audio, in full-duplex mode, would require a total of 128 kbps to be available at each 
person’s workstation for 64 kbps audio going out and 64 kbps audio coming in. 
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E. DESKTOP VIDEO CONFERENCING 



1. Description 

Desktop video conferencing is the next best thing to being there. No longer 
confined to the room-based equipment of the 1980s, video is available on your 
workstation and is almost as easy as using the telephone. Being able to “see” the person 
“adds or improves the ability to show understanding, forecast responses, give non-verbal 
information, enhance verbal descriptions, manage pauses and express attitudes” (Isaacs). 
Video conferencing enables face-to-face interactions with people geographically dispersed, 
without the expense, waste of time, and inconvenience of traveling. 

The process of sending and receiving video over the network is the same as for 
audio. The analog video signal is digitized, compressed and transmitted across the 
network, then decompressed and decoded at the receiving end. A workstation will require 
a digital video camera, a Codec algorithm, and a video capture card, in addition the 
equipment required for audio: microphone, speakers, and sound card (Glover). 

There are two types of video: streaming and real time. Streaming video is pre- 
recorded video that is stored on servers which is played when requested by a user, such as 
movies on demand. The other type is real time video where the video source is created 
while watched, such as video conferencing. 

The quality of the video images is influenced by the frame rate at which the video is 
transmitted, the number of bits used for color depth, and the size of the frame used. 
Video is actually a series of still pictures presented in sequence at such a fast rate that the 
human eye perceives continuous motion. Motion pictures achieve this effect with 24 
frames per second (fps) and television uses 30 fps. Typical desktop video ranges from 4 
fps to 15 fps. 

Video, as displayed on your workstation monitor, is made up many picture 
elements, “pixels”, each of which represents a small dot in the overall image. Depending 
upon the color distinctions required, a pixel can be represented by several bits such as 16 
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bits for over 65,000 colors, or a few bits, such as eight for 256 colors. Sixteen shades of 
gray can be represented in four bits or in eight bits for a finer resolution. 

There are several frame sizes that can be used. Full screen is 640 pixels by 480 
pixels, quarter screen is 320 pixels by 240 pixels, and sixteenth screen is 160 pixels by 120 
pixels. Standards-based frame sizes are the Common Intermediate Format (CEF) of 352 
pixels by 288 pixels, and the Quarter CIF (QCIF) which is 176 pixels by 144 pixels 
(Zeichick). 

2. Standards 

Video is by far the most bandwidth demanding application of all the collaboration 
tools, and compression technology is the single biggest factor that has enabled video to 
occur at the desktop. It is also where interoperability between products becomes an issue. 
Each participant in a video session must be using the same compression algorithms in 
order for the session to even occur. A good detailed discussion of video compression is 
presented in Mark Glover’s Master’s Thesis (Glover). 

Table 2-3 lists additional standards not mentioned earlier in Section B. 



Standard 


Description 


H.261 


Compression for rates > 64 Kbps; defines CIF, QCIF 


H.263 


Compression for rates < 64 Kbps 


H.225.0, H.245 


Communications, signaling, and control for conferences on packet- 
switched networks 


MPEG-1 


(Motion Picture Expert Group) Compression to fit into 1.5 Mbps 
bandwidth 


MPEG-2 


For rates between 4 and 9 Mbps 


MPEG-4 


Low bit-rate compression for rates < 64 Kbps 


Native NV 


Xerox PARC for higher bit rates 


CellB 


Sun Microsystems for higher bit rates 


CUSM 


Cornell CUSeeMe Gray for lower bit rates 


White Pines Color 


White Pines for 24 bit color over lower bit rates 



Table 2-3. Video Compression Standards (MITRE). 
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3. Limitations 



The type of information that can be conveyed by video is generally limited to what 
can be shared by seeing and hearing a person talking and gesturing. Holding up charts or 
slides in front of the camera for viewing by other session participants is ineffective - the 
resolution will not be good enough for the documents to be read. Other than faxing or 
emailing documents out prior to a video session, other collaboration tools such as 
whiteboard or shared applications can be used when there are documents to discuss. 
Many video products come bundled with these capabilities and their use requires 
additional bandwidth. 

The limit on the number of video windows that can be displayed on your monitor 
simultaneously can be anywhere from two to twelve or more, with workstation 
performance degrading as more video windows are displayed. 

4. Bandwidth Requirements 

Acceptable quality is frequently determined in the eye of the viewer and will be 
constrained by the available bandwidth. Most products enable the user to scale the 
number of frames per second, set a limit on the amount of bandwidth to be used, or set the 
amount of compression to perform. Video can be compressed up to 20: 1 and still deliver 
a reasonable picture (CISCO). 

Another technique to conserve bandwidth is called motion compensation, in which 
only the bits in a video frame which represent movement since the last frame are 
compressed and transmitted. For example, in a video of a seated person talking, only the 
bits associated with the movement of the person’s face, and the occasional head or hand 
movement is transmitted. For the most part, the rest of the scene in the video is static and 
the bits would not be refreshed as often. 

Table 2-4 gives a feel for how many bits are required for one second of video for 
two frame sizes (CIF, QCIF), using four bits per pixel (for 16 shades of gray), and varying 
frames per second from 4 fps to 15 fps. The numbers derived in the frame compression 
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column were simply calculated to give an idea of what a 20: 1 compression ratio would be 
and they are not the exact numbers a Codec algorithm might derive for a 20:1 ratio 
setting. 



Frame Size 


Total 

pixels/frame 


Number of 
gray bits 


Total 

bits/frame 


Frame 

Compression 

(20:1) 


Frame rate 
(fps) 


Total Bits for one 
second of Video 


CIF 

(352 X 288) 


101,376 


4 


405,504 


20275 


4 


81,100 


CIF 

(352 X 288) 


101,376 


4 


405,504 


20275 


15 


304,140 


QCIF 

(176 X 144) 


25,344 


4 


101,376 


5069 


4 


20,276 


QCIF 

(176 X 144) 


25,344 


4 


101,376 


5069 


15 


76,035 



Table 2-4. Total Bits for One Second of Video (Author). 



Based on Table 2-4, a minimum of about 20 Kbps would be needed for a video 
conference transmitting at 4 frames per second. At this frame rate, any movements at the 
source may appear jumpy to the receiver, but a meaningful interaction is still possible. 
Now, add 64 Kbps for audio and the total bandwidth required would be about 84 Kbps for 
each participant. In a conference with two people, each workstation would need at least 
168 Kbps: 84 Kbps for outgoing video and audio and 84 Kbps for the incoming video and 
audio. 



F. WHITEBOARD 
1. Description 

Conference rooms usually have a whiteboard or blackboard present for use during 
meetings to draw diagrams or charts, list issues, or record action items. Electronic 
whiteboards carry this same concept to your computer screen and across the network. A 
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picture is displayed as a backdrop and each participant in the session uses a uniquely 
colored marker to gesture, point, draw, or type text on top of the picture in a non- 
destructive mode. What you see on your screen is what everyone else sees and shrinking 
or scrolling the picture will change everyone’s view. 

The displayed pictures can be maps, charts, imagery, still video, or briefing slides 
which are imported or captured from other applications and pasted or “snapped” into the 
whiteboard area. Any participant can snap in a new backdrop picture during the 
whiteboard session. Completed whiteboards with annotations can be exported and saved 
for later reference by any of the participants. 

Whiteboard combined with audio has been called the “premier collaboration tool” 
due to the ease at which a wide range of information can be shared among geographically 
dispersed people in real time from a network workstation (MITRE). 



2. Standards 

ITU T.126 defines a protocol for viewing and annotating still images transmitted 
between two or more applications, often referred to as document conferencing or shared 
white board. 

3. Limitations 

The number of participants should be kept low to ensure a productive session. In 
fact, many products have limitations on the number of uniquely colored markers that are 
available, ranging from eight to 15. Whiteboard is best when used with text chat or audio 
to enable participants to provide running commentary about the annotations they place on 
the displayed pictures. This will increase the bandwidth required for the collaborative 
session. 

Interoperability issues between products exist due to the different ways vendors 
implement the operations the annotation tools perform on the picture backdrops and how 
the whiteboard session is established and controlled. 
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Not all file types can be imported or exported. Many products can not import 
Graphical Interchange Format (GIF) files or export to National Imagery Transmission 
Format Standard (NITFS) (MITRE). 



4. Bandwidth Requirements 

A whiteboard session is bursty in nature, as there is an increase in the bandwidth 
required when a backdrop picture is initially distributed to all participants. The size of the 
burst depends on the type of picture transmitted, whether it is a chart, map, briefing slide, 
or still image. Table 2- 5 provides examples of relative sizes of document types that may 
be used in whiteboard sessions. The annotations that occur on the backdrop picture use 
relatively low amounts of bandwidth, about 2.4 kbps per participant (MITRE). 

In general, a whiteboard session will tend to use less bandwidth than the 
accompanying audio (Floyd). 





Picture 


Size (pixels 
by pixels) 


Total Bytes 


Total Bits 
(8 bits/byte) 


Number of bits with 
compression (20:1) 


1 


Weather - Current Satellite View (Korea) 


384 X 256 


196824 


1574592 


78730 


2 


Weather - Forecast Map 


400 X 300 


240216 


1921728 


96086 


3 


Imagery (West Baghdad) 


1119X739 


1648856 


13190848 


659542 


4 


Hydrographic Chart (Montserrat) 


514X692 


987608 


7900864 


395043 


5 


Topographical Map 1:20,000 Scale 


1087 X658 


1432024 


11456192 


572810 


6 


MS Rjvverptint Slide (graphics) 




118000 


944000 


47200 


7 


MS Rn\expoint Slide (text) 




72000 


576000 


28800 



Table 2- 5. Picture Bit Sizes (N1MA, Author). 
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G. METHOD OF NETWORK DELIVERY 



Communication among human beings can occur in these formats: person to person, 
from one speaker to a large audience, and from many people to many people as in a 
meeting or via a bulletin board. Collaboration tools have evolved and enable humans to 
continue these forms of communications over computer networks. Many computer 
communications are point to point, such as email from sender to receiver, file downloads, 
web accesses, clients accessing servers to run applications. Many to many or 
“multipoint” communications can take place with the use any of the collaboration tools 
described in this chapter, but these applications are bandwidth intensive. Compression is 
one technique used to conserve bandwidth. Another approach is to streamline delivery 
across networks. There are three general methods for multipoint delivery: Unicast, 
Broadcast, and Multicast. Figures 2-1, 2-2, and 2-3 graphically describe these methods. 



1. Unicast 

In this method, the sender’s application transmits one copy of each packet of 
information to each conference participant using individual addresses. This method does 
not scale well to large groups and wastes bandwidth since multiple copies may travel 
shared paths through the network. The burden in this method is on the sender’s host 
computer, which must send out the same number of information packet copies as the 
number of intended receivers. Delays in transmission will occur when the sender is 
bandwidth limited. 

In a collaborative session, the sender may be sending out audio and/or video 
streams to two other participants, as well as receiving audio and/or video streams from the 
two participants. Therefore, in an audio conference using 64 kbps audio, the sender 
would be sending 128 kbps and receiving 128 kbps. A total of 256 kbps must be available 
at the sender’s workstation. 
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2. Broadcast 



A sender’s application transmits one copy of each packet of information using a 
reserved address for broadcast traffic. The information is delivered to everyone on the 
network regardless of the need for the information. Those nodes that do not need the 
information just discard it. This method is extremely wasteful of bandwidth in situations 
where only a small number of nodes want to receive the information. In this case, the 
bandwidth burden is placed on the network itself and its available capacity. 

For use in a collaborative session, video could be broadcast from the site where the 
speaker is out to the other session participants, thereby reducing the number of outgoing 
streams from the sender but the communication will be one-way only. Broadcast 
transmission is also good for distributing static information such as pictures for 
whiteboard sessions. 



3. Multicast 

This method enables the sender to send one copy of each packet of information 
using a reserved address designated for nodes that want to receive the information. As the 
packets traverse the network, multicast routers are on the lookout for this special address 
on behalf of interested nodes in their subnets. If a multicast router has no nodes interested 
in the packets, it forwards the packets on to the next hop. If there is interest, the multicast 
router will replicate the number of copies needed and deliver the packets to those specific 
nodes within its subnet. For an in-depth technical discussion of IP Multicast, refer to 
(Glover). In general, overall network bandwidth use is minimized since the number of 
duplicate network paths the packets take is reduced. However, store and forward or 
processing delays may be increased at the multicast routers. 

This method also significantly reduces the amount of bandwidth required at a 
sender’s workstation. For example, in the audio conference as described above, with 
multicast delivery, the sender would only send out 64 kbps of audio for delivery to two 
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other participants and receive in 128 kbps (two audio streams from other participants) for 
a total of 192 kbps. 



H. SPECIFIC APPLICATIONS 

The Defense Information Infrastructure Common Operating Environment 
Multimedia/Collaborative Services Technical Working Group (DII COE MCSTWG) has 
been established as part of the DII COE and is tasked to define a common core of required 
capabilities for collaboration software services. Appendix A contains lists of these 
requirements for audio, video, and whiteboard applications. 

This working group also conducted an evaluation of audio, video, and whiteboard 
commercial off the shelf products in 1997, the results of which are contained in Appendix 
B. In general, many of the products currently available provide point to point sessions or 
multipoint sessions through the use of Multipoint Conference Servers; multicast delivery 
has not yet been widely implemented. 



L SUMMARY 

Collaboration tools offer many new communication capabilities via computer 
networks. Each tool has varying uses and benefits, but no one tool can do it all. The 
nature of the information to be shared and the available bandwidth will determine which 
tool will be effective. Possessing a variety of these tools will provide greater flexibility 
and adaptability in situations when collaboration with geographically dispersed people is 
required. 
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m. AMPHIBIOUS PLANNING 



A. OVERVIEW 

The planning process, the participants and the types of information discussed during 
planning, is described in this chapter and provides the basis for the operational scenario of 
the simulation model built to analyze bandwidth requirements required for collaborative 
planning by amphibious ships. 



B. ORGANIZATION 

Amphibious ships regularly conduct their operational deployments as an Amphibious 
Ready Group (ARG) which consists of three ships (EWTG): 

• Amphibious Assault General Purpose Ship (LHA) or Multi-Purpose Ship 
(LHD). This ship is the lead or “flagship” of the ARG and will have the 
Amphibious Squadron (PHIBRON) and Marine Expeditionary Unit (MEU) 
Staffs embarked. The mission of the ship is to embark, deploy, and land 
elements of a landing force in an assault by helicopters, landing craft and 
amphibian vehicles. 

• Amphibious Transport Dock (LPD) ship to transport and land troops and their 
equipment and supplies by means of embarked landing craft and amphibious 
vehicles augmented by helicopter lift. 

• Amphibious Dock Landing (LSD) ship. This ship transports and lands troops, 
equipment and supplies of the landing force by means of embarked, pre-loaded 
landing craft and amphibian vehicles. Usually acts as the Landing Craft, Air 
Cushioned (LCAC) control ship in an amphibious operation. 
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At any time during an ARG deployment, one or two of the ships may be temporarily 
detached to perform a specific mission, such as advance force preparations. This 
configuration is called a “Split ARG” and the operating distances are relative and can 
range anywhere within the ARG’s assigned geographical theater of operations. (Clark) 

When an Initiating Directive order is issued the planning phase of an amphibious 
operation is started and the ARG is transitioned into an Amphibious Task Force (ATF) 
and Landing Force (LF) for the purpose of conducting an amphibious operation. The 
ARG forces are supplemented to form an ATF composed of a primary control ship, a 
secondary control ship, landing craft, transport ships, a screen and surface action group, 
minesweepers, and AAW/fire support/ASW ships. The senior Navy officer is designated 
the Commander, Amphibious Task Force (CATF). The Landing Force is commanded by 
the senior landing force officer, usually a Marine Corps officer but could be an Army 
Officer, and is composed of a Battalion Landing Team and Regimental Landing Team. 
Other forces may include the U. S. Air Force, garrison forces, and base construction 
forces. The CATF and CLF are positioned onboard the ATF flagship, an LHA or LHD, 
and it is onboard this ship where the primary planning for the operation occurs. (Kim, 
EWTG) 

C. OPERATIONS 

In general, there are four types of amphibious operations and the conduct of each 
operation is executed following a five-phase sequence of events. 

1. Types 

Amphibious operations can be categorized as follows (Joint Pub 3-02): 

• Amphibious Assault, which involves establishing a force on a hostile or 
potentially hostile shore. 
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• Amphibious Demonstration. An operation using a show of force meant to 
deceive the enemy into executing an unfavorable course of action to its own 
forces. 

• Amphibious Raid. An operation which involves a swift incursion into or a 
temporary occupation of an objective prior to a planned withdrawal. Raids are 
conducted to inflict loss or damage, secure information, create a diversion, 
capture or evacuate individuals and/or material, and execute deliberate 
deception operations. Non-combatant Evacuation Operations (NEO) is a type 
of Amphibious Raid. 

• Amphibious Withdrawal to remove forces from hostile or potentially hostile 
shore to sea in naval ships or craft. 

2. Phases 

Amphibious operations follow a well-defined sequence of events organized into 
five phases: 

• Planning. Starts when an Initiating Directive order is issued to the 
Commander, Amphibious Task Force (CATF) and is done continously 
throughout the operation. Planning is done in parallel and concurrently among 
the staffs of the CATF, CLF, and other participating forces. So much planning 
must occur that Joint Pub 3-02 states that the nature of the planning: 

favors the assembly of commanders and staffs of 
corresponding echelons in the same locality. If such arrangement is not 
practicable, the exchange of liaison officers qualified to perform essential 
planning is necessary. 
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• Embarkation. Period of time in which the forces, with their equipment and 
supplies, embark onto their assigned shipping. 

• Rehearsal. The perspective operation is rehearsed for the purposes of testing 
plans, timing, combat readiness, testing communications, and ensuring all 
participants are familiar with the plan. 

• Movement. During this period, the various elements of the ATF move to the 
points of embarkation to the Amphibious Objective Area, and this phase is 
completed when all ATF forces arrive at their assigned positions. 

• Assault. The timeframe between the arrival of the major assault forces of the 
ATF in the landing area to the accomplishment of the ATF mission. 



D. PLANNING PROCESS 

There are two types of processes employed - deliberate and rapid response; the 
primary difference between the two is the time allocated to perform the planning. 
Deliberate planning occurs continuously within an ARG to maintain a state of readiness 
and ability to quickly respond to any contingencies that may flair up during their 
deployments. Rapid Response planning is the deliberate planning process compressed into 
a six hour evolution. 



1. Deliberate Planning 

There are 15 deliberate planning steps (EWTG): 

1 . Receipt of the mission via Initiating Directive by the CATF and CLF. 
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2. Mission Analysis. Determine the Higher Commander’s intent, the 
purpose, the tasks required to achieve the purpose, and any tactical, 
political, time and space, weather, or rules of engagement limitations. 
Develop assumptions about friendly and enemy force capabilities and 
identify critical vulnerabilities, capabilities, and requirements. 

3. Determine information requirements with regards to intelligence and 
friendly forces required by the Commander for the successful execution 
of the operation. The information may be obtained from sources such 
as maps, charts, imagery, ground sensors, enemy signal 
communications, enemy documents, intelligence documents, and 
weather forecasts. 

4. Initial Staff Orientation. The CATF and CLF will each conduct 
separate meetings with their staffs who are called upon to speak in their 
area of expertise with respect to the operation and contribute 
knowledge in such as areas as terrain, hydrography, the area of 
operations, enemy capabilities, available forces, and logistics support. 

5. Commander’s Planning Guidance. The CATF and CLF staffs get 
together to discuss the operation and the initial basic decisions that 
must be made before detailed planning can proceed. The decisions are: 
ATF general course of action, objectives, the Landing Force mission, 
objectives and concept of operations, the landing site, beachheads and 
landing areas, helicopter landing zones, and the D-Day and H-Hour. 

6. CATF and CLF Commanders issue planning directives that provide the 
schedule and the instructions covering the planning process execution. 
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7. CATF and CLF Commanders provide initial planning guidance, their 
philosophies and issues regarding the operation and the overall plan to 
their staffs to assist in focusing course of action development. 

8. Develop courses of action for accomplishing the mission via 
collaboration between the CATF and CLF staffs. 

9. CATF and CLF commanders are briefed on a range of proposed 
courses of action and approve a general set of potential actions. 

10. The staffs conduct estimates of supportability of the general set of 
selected courses of action using the criteria of suitability, feasibility, 
acceptability, and completeness. 

11. Commander’s Estimate document is prepared. 

12. Development of the Concept of Operations which describes how the 
commander intends to use the forces at hand to accomplish the mission. 

13. Preparation of detailed plans on selected course of action. 

14. Approval of the plan by the Commander. 

15. Continued supervision by the Commander and Staff to ensure the plan 
is updated until required or executed as intended. 
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2. Rapid Response Planning 

When amphibious units are required to conduct a rapid execution of certain 
missions, the planning process is compressed into six hours, and emphasis is placed on 
using verbal briefs with standardized slide formats vice generating written documents. 
The six hours are allocated as follows: 

• First hour and 30 minutes is spent on the first 12 steps of the deliberate 
planning process listed previously. Primary planning location is onboard the 
ATF Flagship and conducted by a Crisis Action Team (CAT). The CAT 
consists of the PHIBRON Commanding Officer, N2, N3, N4, N5, and N6; the 
MEU Commanding Officer, Executive Officer, S2, S3, S4, S6, and Staff Judge 
Advocate; a meteorologist, major subordinate elements of the Landing Force, 
and any other individuals the CATF or CLF designate. During this timeframe, 
various information is shared: the meteorologist provides a weather brief; N2 
/S2 provides intelligence, enemy order of battle, threat and country briefs; 
N3/S3 discuss landing areas with maps and charts; the Staff Judge Advocate 
covers the Rules of Engagement; N3/S3 briefs the status of friendly forces; and 
the PHIBRON and MEU commanders deliver their initial planning guidance. 

• One hour and 30 minutes is spent developing detailed plans. 

• One hour is spent conducting a confirmation brief, which covers the 
commander’s approval of the plan the concept of operations. The execution 
order is issued verbally. 

• Last two hours are used to brief the troops, complete readiness checklists, and 
to conduct drills and rehearsals. 
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E. PARTICIPANTS 



Currently, many of the primary planning participants are organic to the ATF and 
located onboard the flagship. If not already onboard, the appropriate personnel are 
delivered via helicopter to the flagship in order to conduct face-to-face meetings. If 
representation is needed at the Joint Task Force level, ATF liaison officers are placed 
onboard the JTF Command ship. 

Emphasis on "joint" (more the one Service is involved) or "combined" (forces other 
than U S. only are also participating) operations in response to global contingencies only 
serves to increase the necessity of collaboration and coordination by the ATF or ARG 
with outside organizations. Planning must be conducted across Services or Combatant 
command staffs and with other countries' staffs to compose situation assessments, develop 
courses of action, and to coordinate resources. Additional expertise may be required 
from outside organizations, such as a Joint Intelligence Center, National Imagery and 
Mapping Agency (NIMA), a weather center, Modeling and Simulation centers for course 
of action analysis, and from other federal agencies such as the State or Commerce 
Departments, in order to plan an amphibious operation. 
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IV. MODEL SETUP 



A. OVERVIEW 

As a general representation of collaborative planning conducted by an Amphibious 
Ready Group (ARG), a nine node, three router network was built and the flow of audio, 
video, and whiteboard information among the nodes was simulated. This chapter will 
provide details on the simulation modeling tool used, the operational scenario considered, 
how the collaborative sessions were derived as well as other model parameters, and the 
type and number of model runs conducted. 



B. SIMULATION MODELING TOOL 

An object-oriented modeling program developed by Imagine That, Inc., called Extend, 
was used to build a nine node, three router network. Extend can be purchased for under 
$1000.00. Minimum system requirements include: 

• Windows 3.1+, 95, or NT 4.0+ 

• 486 or Pentium-type processor with at least 16 MB RAM and 24 MB hard 
disk space 

The specific machine used was a Gateway 2000, Pentium II 300 MHz processor, with 
32 Megabytes RAM, two-gigabyte hard drive and Windows 95 operating system. Mnor 
problems were experienced with an Extend “out of memory” error that prevented some 
model runs from being simulated for the desired amount of time. The affected model runs 
are pointed out in Section E of this chapter. 
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C. OPERATIONAL SCENARIO 



The operational backdrop for the network modeled was loosely based upon the 
amphibious planning process used by an ARG for planning a landing. The types of 
information most likely to be shared and the number of participants involved during 
planning were derived from the material presented in Chapter HI. Current planning 
practices involve interactions among personnel primarily located on the ARG Flagship, 
which can be considered as one node in a network. In the simulation model, a range of 
locations is used, from two to nine nodes, to portray planning in a more distributed 
environment. 



D. MODEL PARAMETERS 

The objective of the simulation model was to analyze various combinations of 
bandwidth, type of collaboration session, network delivery method, and number of session 
participants, in an effort to derive a desirable bandwidth for collaborative planning. There 
were four significant parameters used in the model and their descriptions follow. 



1. Bandwidth 

Three bandwidth settings were used: 128 kbps, 256 kbps, and 384 kbps, which 
were derived from the matrix listed in Appendix C. A1 collaboration participants were 
assumed to have the same amount available. Varying the bandwidth amounts among the 
network nodes was not simulated. Collaboration tools are used to perform 
communications in real-time. Possessing a higher bandwidth provides no speed advantage 
over a lesser-equipped site since both sites are communicating together, at the same time. 
The site with higher bandwidth will actually be constrained to operate at the lower 
bandwidth level of the least capable participant, so all nodes in the model were modeled 
with the same amount. 
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2. Number of Collaboration Participants 

Two, three, six, and nine nodes were used to simulate communications among two 
or three ships in an ARG and the ARG with three or six other sites. These other sites 
represented a Carrier Battle Group or shored-based sites such as support elements for 
landing team, weather centers or intelligence centers, Fleet Staffs, and other Services or 
government agencies, any one of which may play a part during the collaborative planning 
process being conducted by the ARG. 



3. Network Delivery Method 

Two delivery methods were simulated: Unicast and Multicast, which were 
described in Chapter II. Maximum node participation was assumed in both methods. In a 
nine node Unicast scenario, a node would send out eight individual text chat, audio, video 
or whiteboard bit streams destined for the eight other nodes. In a nine node Multicast 
scenario, a node would send out one text chat, audio, video, or whiteboard bit stream and 
the routers would replicate and route the bit streams to reach the eight other nodes. 

The specific details of packet delivery, losses and retransmissions and various types 
of routing protocols were not modeled. The high level effect of modeling these two 
delivery methods was to stress the bandwidth available at a node as the node attempted to 
send out the required number of audio and video streams to other nodes participating in a 
collaborative session. 



4. Collaboration Sessions 

The exact nature of the information to be discussed at any particular time during a 
planning session will not always be known or the same each time planning is conducted. 
Fortunately, the information to be shared during a collaboration session does not have to 
be modeled explicitly. Each collaboration tool and its use in combination with others 
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provides the means to transport the planning information across the network, and it is the 
capacities of these tools that can be modeled. The following paragraphs describe the 13 
different collaboration sessions used in the model and how they were derived. 

a. Text Chat 

A generic message size was set at 100 words. Assuming an average of five 
characters per word and using eight bits per character, the text chat message size was set 
at 4000 bits. For a text chat collaborative session it was assumed that each node would 
send out a message every V 2 minute and more than one node could put out a message at a 
time. The nodes did not have to take turns or wait for messages for other nodes to arrive 
prior to sending out any messages. 

b. Audio Conferencing 

Full duplex mode was used so each node could hear and speak simultaneously. 
Nodes did not have to take turns to speak. Using rates derived from the matrix in 
Appendix C, two sessions were built: 

• Low rate audio of 14.4 kbps. 

• High rate audio of 64 kbps. 



c. Video Conferencing 

Video Conferencing was not done in stand-alone mode, all sessions included 
audio. As in the audio conference sessions, audio was in full-duplex mode and nodes did 
not have to take turns to speak. All nodes could see video and hear audio from each of 
the other participant nodes simultaneously. Video was based on the QCIF frame size of 
176 pixels by 144 pixels, grayscale with four bits per pixel, frame compression rate of 
20:1, and a low rate of 4 frames per second (fps) and a high rate of 15 fps. Table 2-4 
shows the bit sizes derived for one second of video with these characteristics. The 
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resulting combinations of low audio and video with high audio and video generated four 
video conference collaborative sessions: 

• Video at 4 fps and Audio at 14.4 kbps, for a total of 34,676 bits per second. 

• Video at 4 fps and Audio at 64 kbps, for a total of 84,276 bits per second. 

• Video at 15 fps and Audio at 14.4 kbps, for a total of 90,435 bits per second. 

• Video at 15 fps and Audio at 64 kbps, for a total of 140,035 bits per second. 



cL Whiteboard 

Whiteboard sessions tend to be bursty in nature as the pictures for backdrops 
are initially sent to all participants then displayed for a period of time to enable annotations 
and discussion. During a session, it was assumed that a single node would transmit all 
whiteboard pictures to each of the other nodes. All nodes were sending audio and video 
to the other nodes while waiting for the whiteboard pictures to arrive. In a collaborative 
session, productive discussions could continue during this waiting period while the 
whiteboard backdrop pictures are updated. The receiving nodes could not begin 
annotations until the picture had been received and then the nodes took turns to annotate. 
For example, in a three node scenario, each node would have to wait two time steps 
before sending its annotation bit stream of 2.4 kbps. Picture 5, the topographical map 
consisting of 572,810 bits was selected from Table 2-5 and used as the picture transmitted 
in the whiteboard session. This map is a good example of what might be displayed during 
an Amphibious Landing collaborative planning session. Like video conferencing, 
whiteboard is typically not done alone - it is usually accompanied by audio or video and 
audio together. Whiteboard combined with the various audio and video rates resulted in 
six sessions: 
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Whiteboard (Wb) and Audio at 14.4 kbps. 



• Wb and Audio at 64 kbps. 

• Wb and Video at 4 fps and Audio at 14.4 kbps. 

• Wb and Video at 4 fps and Audio at 64 kbps. 

• Wb and Video at 15 fps and Audio at 14.4 kbps. 

• Wb and Video at 15 fps and Audio at 64 kbps. 



E. MODEL RUNS 

Over 170 different variations of the basic model were executed. A discussion of the 
Extend model structures that were built, the measure of effectiveness used and the various 
run combinations are provided in the following paragraphs. 

1. Basic Model Structures 

The node and router structures used in the model will be described and are shown 
in Appendix D. These basic structures were then used as building blocks and replicated as 
needed for a six node or nine node network model. Storage requirements varied from 
1,176 Kbytes to store a two node model file to 4,200 Kbytes for a nine node model file. 

a. Node Structure 

Each node sends out text chat, audio, or video messages containing the 
number of bits representing the specific collaborative session being simulated. Only one 
node sends out whiteboard message bits. Each node also receives text chat, audio, video 
messages from other nodes and receives whiteboard messages from one designated node. 
Time Division Multiple Access (TDMA) mode, using a clock step of 2 milliseconds, was 
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used to alternately allow designated outgoing messages out from the node to the router 
and allow incoming messages in from the router to the node. After passing the TDMA 
gate, all messages are placed into a common first-in, first-out queue. No priorities were 
assigned based on the type of message - each is handled on a first-come, first-served basis. 
A transmission delay is then calculated using the bit size of the message divided by the 
amount of bandwidth available at the node to determine the amount of time required to 
send or receive a message. After the delay, outgoing messages are sent to the router and 
incoming messages are sorted and stored by source node. 

b. Router Structure 

A router has three nodes in its subnet. A message destined for a node within a 
router’s subnet is sent directly to that node by the router. A messagedestined for a node 
in another subnet is sent to the router serving that subnet. In Unicast delivery mode, the 
router simply executes a decision tree to decide which subnet nodes or routers are to 
receive the message and forwards the message to those destinations. In Multicast delivery 
mode, a router replicates the message for delivery to its subnet nodes and forwards copies 
of the message to the other routers. No delays were simulated for any processing which 
occurs at the routers or for the transmission time required for messages to reach the other 
routers. In general, the differences between the processing delays induced by a regular 
router and by a multicast router are negligible (Brutzman, Macker, Novotny). The 
simulation model was built to see how limiting the bandwidth is at the node and not 
throughout the network. 



2. Measure of Effectiveness 

For collaborative sessions to be viable, the amount of delay in receiving audio bit 
streams must be at least under 500 milliseconds and video must be at least under 95 
milliseconds for reasons described in Chapter II. The quality of service for video is more 
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subjective than audio and video frame rates that simply provide an indication of presence, 
not movement, at other sites may be acceptable and not necessarily take away from the 
success of a collaborative session. Therefore, more emphasis was placed on using 500 
milliseconds or less as an acceptable level of delay for the amount of time for a text chat, 
audio, video message to leave one node and arrive at another node. Whiteboard messages 
tended to take longer than 500 milliseconds and delays are a direct factor of the size of the 
picture and the amount of bandwidth available to transmit and receive the picture. 
Measurements were taken separately for whiteboard simply to record the amount of delay 
that occurred in the different parameter combinations. Within the Extend models, 
outgoing messages were tagged as soon as they were generated at a node and their arrival 
times at the destination nodes were measured. Measurements were taken within a subnet 
and across to other subnets as follows: 



• Two node scenario. Node 1 to node 2 and node 2 to node 1 for text chat, 
audio, and video. Whiteboard from node 1 to node 2 only. 

• Three node scenario. Node 1 to node 2, node 2 to node 3, and node 3 to node 
1 for text chat, audio, and video. Whiteboard from node 1 to node 2 and node 

3. 

• Six node scenario. Node 1 to node 6, node 2 to node 3, and node 6 to node 1 
for text chat, audio, and video. Whiteboard from node 1 to node 3 and node 6. 

• Nine node scenario. Node 1 to node 9, node 2 to node 3, node 6 to node 1 for 
text chat, audio, and video. Whiteboard from node 1 to node 3, node 6, and 
node 9. 
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3. Simulation Run Time 



A simulation run time of 100 seconds was selected. Extend required 
approximately three minutes to execute a two node model, four minutes for a three node 
model, 1 1 minutes for a six node model and 23 minutes to execute a nine node model. 

Other simulation run times were tried: 180 seconds, which took approximately 26 
minutes for a six node scenario to execute, 240 seconds which took 33 minutes, and 300 
seconds which took 40 minutes to execute. The measured delays from models executed 
with the longer simulated run times were compared to those captured in model runs for 
100 seconds and no significant differences were noted. The delays appeared to 
consistently occur among the nodes in similar patterns and at a similar ratios, so 100 
seconds was selected as the simulation run time for all models. 

For the majority of the runs executed, 100 seconds was more than ample time to 
get text chat, audio, video and whiteboard messages delivered among the nodes. 
Messages that took longer than 100 seconds were well beyond the acceptable range as 
described previously. 



F. RUN COMBINATIONS 

With the number of parameters described in Section D above, many run combinations 
were possible. The strategy to reduce the number of runs yet execute some meaningful 
combinations was to first run combinations at each end of the node spectrum, three and 
nine nodes, and establish some “baseline” runs. The next step was to examine the run 
results against the selected measure of effectiveness and identify those combinations that 
were successful. These runs became the “focused” runs and the parameters were further 
modified. “Special” runs were executed for a high-level look at a point-to-point 
collaboration scenario and two different locations for a multicast router - on a satellite or 
at a shore location. Appendix E contains a matrix of the various model parameter 
combinations that were executed. 
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1. Baseline Runs 



The parameters used were three and nine nodes, 128 and 384 kbps, Unicast and 
Multicast delivery, and all 13 different collaborative sessions. The various combinations 
resulted in a total of 104 runs executed. 

Difficulties were encountered with runs that tended to be at the high end for 
stressing the model: 9 nodes, 128 kbps, Unicast delivery, and collaborative sessions with 
whiteboard, video and audio combinations. At this bandwidth, many nodes did not 
receive any whiteboard, video or audio messages from some of the other nodes during the 
specified simulation run time of 100 seconds. A larger simulation run time of 180 was 
selected and some nodes still did not receive messages. A run time of 240 seconds was 
then used and Extend ran out of memory for building arrays used to maintain state 
information about the model. As a result, several of the nine node runs did not generate 
any data for the measure of effectiveness - the amount of time for a message from one 
node to arrive at another node. Examination of the data that was collected for delivery 
times to other nodes revealed that the messages in those affected nine node runs would 
have been far beyond the acceptable range for audio or video. The measured delays 
recorded for the affected nine node runs were set to 100 seconds to reflect a “maxed out” 
state for those runs. This clearly sets the affected runs apart from the other successful 
runs and is reflected in the graphs presented in Chapter V. 



2. Focused Runs 

Three collaborative session types were selected from the baseline runs: video at 4 
fps and audio at 14.4 kbps, whiteboard with audio at 14.4 kbps, and whiteboard with 
video at 4 fps and audio at 14.4 kbps. These session types represent the spectrum of 
capabilities that are offered by collaboration tools, and the rates selected show the most 
promise for message deliveries with the acceptable delay of 500 milliseconds. 
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New runs were generated using the parameters: two, three, six, and nine nodes, 
bandwidths of 128, 256, and 384 kbps, Unicast and Multicast delivery methods, and the 
three collaborative session types mentioned above. The various combinations resulted in a 
total of 72 runs executed. 



3. Special Runs 

These additional 18 runs were constructed to examine specific aspects in an 
amphibious planning scenario, such as point-to-point collaboration between two ships in 
Line of Sight (LOS) mode and the effect of location of the multicast router on message 
delays for a three ship ARG. Two locations of a multicast router were simulated - one 
onboard a geostationary satellite using a 240 millisecond round-trip propagation delay and 
the other via a geostationary satellite link to a shored-based router located at a facility 
such as a Naval Computer and Telecommunications Area Master Station (NCTAMS). In 
both multicast router scenarios a 1200 millisecond generic router processing delay was 
implemented (O’Reilly). 

G. SUMMARY 

An overall representation of collaboration planning conducted by an Amphibious 
Ready Group (ARG) was built from the aspect of the collaboration tools available and the 
data rates required for their viable use. Several combinations of collaboration tools, 
bandwidths, participants, and network delivery methods were executed via a simulation 
tool in an effort to assess which combinations showed more potential for success. No 
delays associated with protocols, routers or network congestion were simulated. In effect, 
the “best case” for text chat, audio, video, and whiteboard message delivery was simulated 
which only served to highlight the impact that a planning participant’s available bandwidth 
has on the conduct of a collaborative session. 
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V. MODEL RESULTS 



A. OVERVIEW 

Over 170 model runs were executed in an effort to provide some insight into the 
question, “How much bandwidth is required for collaborative planning?” The amount of 
bandwidth available to a ship will limit the collaboration tool that can be used and the 
number of dispersed planners that can be involved in a session - the usual trade off 
between resources and capabilities. 

An examination of the average message delays measured for the various parameter 
combinations indicate that two or three nodes can successfully conduct a wider range of 
collaboration session types at 128 kbps when Multicast delivery is implemented. A 
whiteboard session with accompanying audio and video among two or three nodes is 
untenable at 128 kbps with Unicast implemented. A bandwidth of 256 kbps enables up to 
six nodes to conduct a whiteboard with audio session. An even higher bandwidth of 384 
kbps provides the ability of six nodes to collaborate via whiteboard with video and audio 
and for nine nodes to get together in a whiteboard and audio session. 

This chapter will present the results and interpretations of the Baseline, Focused and 
Special Runs. Appendix F contains the Extend model results. 



B. GRAPH FORMATS 

Two basic graph formats are used to present the results of the model runs - a 
Baseline graph and a Parameter graph. All the graphs are presented at the end of this 
Chapter. 
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1. Baseline Graph 

This graph compares the average message delays of text chat, audio, video, and 
whiteboard messages among the nodes in a three node and nine node scenario, across 
collaboration session type. An example is shown in Figure 5-1. The title of the graph 
indicates the network delivery method and the bandwidth used, such as Unicast and 128 
kbps. The X-axis lists the collaboration session types. The Y-axis lists the average delay 
in seconds for a message to travel between two nodes. The plot lines with solid marks 
represent text chat delays or audio and video delays combined. The plot lines with open 
marks represent whiteboard delays. An example of an observation from Figure 5-1 is that 
the three node scenario is the only node scenario with an average delay less than V 2 second 
for the whiteboard and audio (14.4 kbps) session. Refer to Appendix F for actual delay 
measures. 




Figure 5-1. Baseline Graph 
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2. Parameter Graph 

The purpose of this graph is to examine the average delays for message 
deliveries for a specific model parameter across the remaining three model parameters and 
identify trends or rates of change in performance. Figure 5-2 is an example of this graph. 
The title indicates the parameter being examined, such as the number of nodes. The X- 
axis lists the three other parameters - bandwidth, delivery method, and session type. The 
Y-axis lists the average delay in seconds for a message to travel between two nodes. The 
plot lines are the same as those in the baseline graphs. An example of an observation is 
that as the bandwidth increased, the average delays for whiteboard decreased more 
significantly than did the delays for video/audio. 



2 Nodes 







-•—Video/Audio 

-e-Wb 



Figure 5-2. Parameter Graph. 



C. BASELINE RUNS 

Twelve baseline graphs which compare average delays across all combinations of 
bandwidth and network delivery methods are presented in Figures 5-3, 5-4, 5-5, and 5-6. 
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As mentioned previously in Chapter V, the nine node runs using 128 kbps and Unicast 
delivery were so bandwidth limited in the whiteboard session types that several nodes did 
not receive audio, video or whiteboard messages. All average delays at or above 70 
seconds in Figure 5-3 c reflect this occurrence. 

Interpretations from Figures 5-3, 5-4, 5-5 and 5-6: 

• Average delays are reduced as bandwidth is increased from 128 kbps to 384 
kbps. 

• Multicast delivery reduces the amount of delay. This is more noticeable in the 
nine node runs. Multicast enables a node to send out one copy of a message 
instead of tying up all the bandwidth to send out eight copies. It is also faster 
to send out one message vice eight, so the time saved sending messages can be 
used to receive messages. 

• In Figure 5-3c, the plot line for “9 node” shows a slight decrease in average 
delays for the most stressing collaboration session combination: whiteboard 
with high frame rate video and high rate audio. Since only one node is sending 
out whiteboard pictures to all the other nodes this particular node basically 
became stalled at 128 kbps trying to send out the pictures. The other nodes 
did not have their bandwidth tied up receiving a whiteboard picture, so they 
were receiving and sending video and audio messages with less delays. In 
other words, the collaboration went on despite the problems encountered by 
one node. 

• Figures 5-3c, 5-4c, 5-5c, and 5-6c show a “dip” in the average delay for the 
session type “Whiteboard with video at 4 fps and audio at 14.4 kbps rate.” 
The messages for this session type requires 34, 676 bits per second, less than 
most of the other whiteboard session types listed in Table 5-1. The messages 
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in that session type can be sent out faster and received faster which results in 
lower delays. The whiteboard picture was held at a constant size of 572,810 
bits across all whiteboard session types. 



Collaboration Session Type 


Total AudioA/ideo 
Bits 


Wb + Audio (14.4 kbps) 


14,400 


Wb + Audio (64 kbps) 


64,000 


Wb + Video (4 fps) + Audio (14.4 kbps) 


34,676 


Wb + Video (4 fps) + Audio (64 kbps) 


84,276 


Wb + Video (15 fps) + Audio (14.4 kbps) 


90,435 


Wb+ Video (15 fps) + Audio (64 kbps) 


140,035 



Table 5-1. Collaboration Session Bit Totals. 



• In addition to text chat and audio conferencing at 14.4 kbps, three other 
collaboration session types show potential for being viable combinations for a 
three node scenario. The sessions are: video (4 fps) with audio (14.4 kbps), 
whiteboard with audio (14.4 kbps) and whiteboard with video (4 fps) and 
audio (14.4 kbps). These sessions had average delays near or below the V 2 
second measure of effectiveness. These session types also appeared to be 
viable for nine node scenarios at a higher bandwidth of 384 kbps. These three 
session types were selected for additional runs with parameter settings of 2 and 
6 nodes, and 256 kbps. 

D. FOCUSED RUNS 

Several graph sets are presented in this section to enable comparisons across the 
parameter values used in the model. Comparisons were conducted by number of nodes, 
bandwidth, session type, and delivery mode. 
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1. Number of Nodes Comparison. 

Six graphs are presented in Figures 5-7 and 5-8, showing Unicast delivery and 
Multicast delivery. Three bandwidths are represented: 128 kbps, 256 kbps, and 384 kbps 
and four node sizes: 2, 3, 6, and 9. 

Interpretations of Figures 5-7 and 5-8: 



• A bandwidth of 384 kbps with Multicast delivery enables two to nine nodes to 
successfully engage in all three collaboration session types. 

• In a low bandwidth environment, whiteboard with audio at 14.4 kbps or video 
at 4 fps with audio at 14.4 kbps can be used for sessions with two or three 
nodes. 

• Whiteboard delay times are more constant across all bandwidths in Multicast 
delivery mode than in Unicast mode. The sending node sends one copy of the 
whiteboard picture in Multicast mode and the network is responsible for 
delivery to the other nodes. In many cases the delivery will appear to be 
“simultaneous” at all nodes, with small delays occurring that are very close in 
duration. Under Unicast mode, the sending node is limited by its bandwidth 
and is generally reduced to sending the pictures to the other nodes in series, so 
the last node on the distribution list will experience longer delays than the first 
node on the list. 

• In a two node scenario, no significant difference in message delays was shown 
between Unicast and Multicast delivery methods. In each method, a node is 
only sending one copy of a message. There are no advantages gained by 
employing Multicast delivery in a point to point communications scenario. 
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2. Bandwidth Comparison 

Three graphs are presented in Figure 5-9 which show, as expected, that a higher 
bandwidth reduces delays and enables the use of collaboration tools among a larger 
number of participants. 

3. Session Type Comparison 

Interpretations for the graphs of three collaboration session types in Figure 5-10, 
are as follows: 

• Multicast delivery significantly reduced the amount of delay in the largest 
session (in terms of bit size): nine nodes using whiteboard with video at 4 fps 
and audio at 14.4 kbps, but it was not enough to get the delays below the 
acceptable level of Vi second. In general, Multicast delivery reduces the 
bandwidth needed for one transmission by a node intended to reach many 
destinations. But Multicast delivery does not reduce the bandwidth required at 
the node to accept many streams of audio and video from other collaborating 
nodes. The limit on the number of session participants is constrained by the 
bandwidth at a node. 

• Whiteboard delays were greater than audio and video delays in Figure 5- 10b 
and less than audio and video delays in Figure 5- 10c. The whiteboard picture 
consisting of 572,810 bits, was large, even when compared to the maximum of 
eight audio messages that one node sent out (115,200 bits) and received in 
(115,200 bits) for a total of 230,400 bits in the nine node scenario. All these 
bits were competing for bandwidth with the whiteboard at the node so the 
whiteboard took slighter longer to receive than 115,200 bits. However, in 
Figure 5- 10c, the maximum combination of eight audio and video streams 
almost doubled to 277,408 bits and, the whiteboard was now competing with 
incoming and outgoing streams at the node totaling 554,816 bits. The 
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whiteboard delay did increase but did not double as did the delays for the audio 
and video messages. 

4. Delivery Method Comparison 

Figure 5-11 presents the two delivery methods of Unicast and Multicast. As 
expected, there were lower delays overall when Multicast delivery was implemented. 



E. SPECIAL RUNS 

Two special runs were conducted: one to simulate a point-to-point Line of Sight 
scenario that is common between two ships and another run to compare two locations of a 
multicast router. 

1. Point-to-Point Communications 

The results shown in Figure 5-12 are similar to those of the two node scenario 
results presented earlier. 

• Multicast Delivery does not reduce delays and does not offer any improvement 
over Unicast delivery. 

• A bandwidth of 128 kbps is still slightly limiting in conducting collaboration 
sessions within the Vi second acceptable delay. In general, a bandwidth of 256 
kbps enables all three types of collaboration sessions to occur. 

• Whiteboard delivery delays are greatly reduced when bandwidth is increased, 
as expected. 
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2. Multicast Router Location 



Delays were added to the three node scenario to simulate processing at the router 
and propagation times up to and down from a geostationary satellite. The satellite-based 
multicast router generated the only viable collaboration sessions - whiteboard with 14.4 
kbps audio at 256 kbps and 384 kbps bandwidths, that were within the Vi second 
acceptable delay. No sessions at 128 kbps via the satellite-based router were viable. . The 
additional round-trip required for messages to travel to the shore-based multicast router 
increased delays across all session types and bandwidths - no sessions were within 
acceptable delay range. 



F. SUMMARY 

Table 5-2 provides a summary of the main results of the model runs. The columns list 
combinations of Delivery method with bandwidth sizes and the rows list the number of 
nodes. In each intersection of row and column, there are three letters which represent the 
collaboration session types. The first letter position from the left, represents the video at 4 
fps with audio at 14.4 kbps session type, the second letter position, indicates whiteboard 
with audio at 14.4 kbps, and the third letter is the whiteboard with video at 4 fps and 
audio at 14.4 kbps. The use of the letter “Y” indicates that the collaboration session for 
the combination of delivery method and bandwidth for a particular number of nodes 
executed with messages arriving within the Vi second timeframe for an acceptable session. 
An entry of “N” indicates that the collaboration session type for the particular column/row 
combination did not meet the Vi second criteria for message arrivals. As an example, the 
intersection of Unicast, 128 kbps with 3 nodes is “NNN” which indicates that message 
arrivals for all three session types were not below the Vi second criteria. 
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Unicast, 128 kbps 


Unicast, 256 kbps 


Unicast, 384 kbps 


Multicast, 128 kbps 


Multicast, 256 kbps 


Multicast, 384 kbps 


2 nodes 


YNN 


YYY 


YYY 


YNN 


YYY 


YYY 


3 nodes 


NNN 


YYN 


YYY 


NNN 


YYY 


YYY 


6 nodes 


NNN 


NNN 


NNN 


NNN 


YYN 


YYY 


9 nodes 


NNN 


NNN 


NNN 


NNN 


NYN 


NYN 


1st Letter = video (4 fps) + audo (14.4 kbps) 

2nd Letter = whiteboard + audio (14.4 kbps) 

3rd Letter = whiteboard + video (4 fps) + audo (14.4 kbps) 



Table 5-2. Summary of Results. 



The results presented in Table 5-2 show that at 128 kbps, only two nodes can have 
a video and audio collaboration session. At 256 kbps, two nodes can perform all three 
session types. At 256 kbps bandwidth, the advantages of Multicast delivery over Unicast 
also becomes apparent as more nodes can execute more session types. Three nodes can 
execute an additional session type under Multicast than could be executed under Unicast. 
Six nodes can execute two collaboration sessions under Multicast that could not be 
executed under a Unicast with 256 kbps combination. 

Multicast with 384 kbps, is the combination with the most options as the two, 
three, and six node scenarios could execute all three session types. The nine node scenario 
could execute the whiteboard with audio at 14.4 kbps, and it was very close for the other 
two session types as both averages were just over the 0.5 second threshold: 0.5135 second 
delay for the video (4fps) and audio (14.4 kbps) session and 0.5565 second for the 
whiteboard with video (4 fps) and audio (14.4 kbps). 

A high-level view of a network was built and simulated in an effort to gain insight 
into the use of collaboration tools and using only four general parameters, results were 
obtained that seemed intuitively obvious. The level of detail inserted into the models is 
only limited by the expertise of the model builder. A more detailed look at several aspects 
of collaborative planning at sea and between ship and shore can certainly be built and 
executed within a reasonable timeframe. 
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Figure 5-6 Multicast with 364 kbps 




I 

s 




S S ^.puoE.)Aewa6A^ s 




g 3 WL.AJ 2 




fill 

Illlllll 

N(srtrt(o<D(»<n 



SSS8S8S2 0 

(spuooas) Aejaa Bav 



r-~ 

in 

I 



61 



Figure 5-7 b. Figure 5-7 c. 
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Figure 5-1 1 . Delivery Comparison. 
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Figure 5-12. Point-to-Point. 



VI. CONCLUSIONS 



How much bandwidth does an amphibious ship need in order to perform 
collaborative planning? The goal of this thesis was to provide some insight into this 
question through the use of a high-level simulation model built using a commercial off-the- 
shelf product called Extend. Over 170 model runs were executed with various 
combinations of the three collaboration tool types, the amount of bandwidth, the number 
of planners involved in a planning session, and the type of network delivery method used. 
The results of these runs are presented from three different aspects, by required 
collaboration capabilities, by bandwidth, or by the number of other planners that can be 
involved, as follows: 

• Minimum collaboration capabilty required by the ship. If, at a minimum, a ship 
must be able to conduct a video and audio session with one other ship, than at 
least 128 kbps must be available to each ship. To conduct a whiteboard with audio 
session, at least 256 kbps must be available. Whiteboard with video and audio 
requires 384 kbps. 

• Bandwidth is limited. If a ship only has 128 kbps available, then the ship will only 
be able to conduct a video and audio session with one other ship. At 256 kbps, a 
ship can collaborate via a video and audio session or a whiteboard with audio 
session with up to two other sites. At 384 kbps, using multicast delivery, a ship 
will be able to engage up to eight other sites in a whiteboard with audio session. 

• Number of planners required in a collaboration session. To collaborate with one 
other planner a ship requires at least 128 kbps and a session with two other 
planners, at least 256 kbps. To collaborate with five to eight other planners, at 
least 384 kbps must be available at the ship and multicast network delivery must be 
used to ease the bandwidth congestion at the ship. 
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To ensure flexibility and adaptability in any planning situation a ship may be 
engaged in, an optimum mix might be to provide at least 256 kbps bandwidth and use 
multicast network delivery, so the ship can access some combination of the three 
collaboration capabilities provided by the tools, with up to five planning counterparts. 
Without multicast delivery, at least 384 kbps will be required for three ships to engage in a 
collaborative planning. 

The models in this thesis focused only on the bandwidth availability at the ship 
level and did not model all aspects of network communications and the delays caused by 
network congestion, the routing protocols used or limitations imposed by satellite 
capacities and access allocations. Many future studies are possible which focus on these 
various delays and assess their impact on the use of collaboration tools. 

In amphibious planning, the rapid response planning process is six hours. 
Additional future studies could examine how the use of collaboration tools might affect 
planning timelines or the sequence of planning events. 
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APPENDIX A: DU COE CRITERIA FOR COLLABORATION SOFTWARE 



The Defense Information Infrastructure Common Operating Environment 
Multimedia/Collaborative Services Technical Working Group (DII COE MCSTWG) has 
been established as part of the DII COE and is tasked to define a common core of required 
capabilities for collaboration software services. This appendix contains the requirements 
identified for audio, video, and whiteboard applications. 

1. Audio conferencing software shall provide: 

- Point to point and multipoint, multi-user conferencing 

- Multiple operating modes (e.g., support for interactive conference (people sending 
and receiving from multiple sites), support for one-way conferences (one site 
sending, all other sites receiving) 

- Ability to add/remove users during a conference 
Support for speaker/microphone control. 

- Push to talk 

- Audio mute on send and receive, near and far 

- Support for private side conferences (whisper mode) 

- An adjustable bandwidth control 

- Adaptation to lowest common audio denominator for lower bandwidth participants 
(e.g., automatic protocol negotiation) 

Support down to 2400 baud per second and support up to 8 Khz audio. 

- Support for secure audio conference channel 

- Ability to save and recall audio conference (e.g., in ADPCM, MPEG formats) 

- Gateway to other audio conferencing formats 
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Support for GSM, LPC-10 (2.4), CELP, and G.700 series interoperability 
standards 

- Support for full duplex 

2. Video conferencing software shall provide: 

Point to point and multipoint, multi-user conferencing 

- Multiple operating modes (e.g., support for interactive conference (people sending 
and receiving from multiple sites), support for one-way conferences (one site 
sending, all other sites receiving) 

- Ability to add/remove users during a conference 

- An adjustable frame rate 

- An adjustable compression ratio 

- An adjustable image size 

- Adaptation to lowest common audio and video denominator for lower bandwidth 
participants 

- Support for rate governing 

Support for secure video conference channel 

- Ability to save and recall video conference (MPEG) 

Frame grab video image and save to file (e.g., JPEG, Postscript, GIF) 

- Gateway to other conferencing formats 

- Support for H.320 series interoperability standards 
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3. Whiteboard tools shall provide: 

Support for multiple users annotating simultaneously (including individualized 
cursors that are visually distinct and identify user) 

- Ability to import image formats as whiteboard background, including screen 
capture (window, entire screen, user defined area), N1TF, JPEG, GEF, and 
Postscript 

Support for 8-bit and 24-bit imports 

- Ability to export image background and annotations to JPEG (burned in 
annotations), NITF (nondestructive annotations), Postscript (burned in 
annotations), TIFF (burned in annotations), GIF (burned in annotations) 

- Gesturing/pointing tool 

- Text, line, arrow, rectangle, circle, oval, polygon, free draw annotation tools, multi' 
color annotations 

- Ability to import custom symbols for annotations 
Geopositioning of symbols on imported maps 

- Attributed annotations (e.g., user, date, comments) and the ability to store and 
retrieve meta data with annotations 

- Ability to overlay vectors (e.g., VPF, CGM) on raster backgrounds. 

- Nondestructive whiteboard annotations 

- Ability to add/remove users during session 

- Persistence of whiteboards for on-going collaborations (e.g., ability to save and 
recall state) 

Support for Secure whiteboard sessions 
Support for T. 126 series interoperability standards 

- Plug-in capability to expand functionality 
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APPENDIX B: COMPARISON OF COLLABORATIVE PRODUCTS 



The Defense Information Infrastructure Common Operating Environment 
Multimedia/Collaborative Services Technical Working Group (DII COE MCSTWG) with 
assistance from MITRE, conducted an evaluation of audio, video, and whiteboard 
commercial off-the-shelf products in 1997. The results are presented in the following 
matrixes. 
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tn 

a> 

>- 


Yes, via Multicast 


Multicast 


No 


Yes 


Adjustable frame 
rate; adjustable 
compression by 
selecting new 
encoder; 
adjustable image 
size 


Removal of self 


Yes, via DES 
Encryption 


Yes, FCIF and 
QCIF 


0 

2 


nv; Sun CellB; 
MJPEG; H.261 


Bandwidth limited 


CD 


Paradise Simplicity 
H.323 


q 


Yes (Fall 97) 


Yes (Fall 97) 


Yes (Fall 97) 


tn 

$ 


Yes, via Multicast 
or MCU (Fall 97) 


Multicast first; MCU 
will be added later 


No 


Yes 


Adjustable frame 
rate; Adjustable 
compression ratio; 
Adjustable image 
size 


Removal of self 


Yes 


Yes. FCIF and 
QCIF 


O 

2 


O 

LU 

Q. 

—3 

5 


CM 

CO 


< 




Tool Version 


Solaris 2.5.1 


X 

3 

a. 

X 


IN 


| IP-based 


Multiuser conferencing 
(>2 users) 


1-way broadcast 
conferences (MCU, 
Multicast, Peer to Peer] 


0 
0) 

1 

& 

3 


control 

- Receive only 

- Receive and transmit 


User bandwidth control 

- Adjustable frame rate 

- Adjustable compression 
ratio 

- Adjustable image size 


Dynamic addition/removal 
of users during 
conference 


Conference participation 
control (private, no 
eavesdropping) (Not 
security) 


H.261 


|H263 


Other CODECs 
supported 


Max # users in 
conference 
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<N 


CO 


'M' 


in 


CO 
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0 


- 


CM 


CO 
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Video Conferencing 



— > 


Xerox PARC NV 


Adjustable 
compression by 
selecting new 
encoder; 

Adjustable image 
size 


No 


Yes 


No 


Yes 






- 


White Pines 
CUSeeMe 


Adjustable video 
quality (changes 
frame rate used); can 
select different video 
codecs; adjustable 
image size among 
different predefined 
sizes 


o 

Z 


Yes 


o 

Z 


o 

Z 






X 


Sun ShowMe 


O 

z 


o 

z 


o 

z 


o 

z 


Yes - snapshot 
into Sun Raster 
format 


Video Mute; also. 

Sun has an 
H.323 product in 
the works 




o 


PictureTel LiveLAN 


Adjustable frame rate; 
Adjustable 
compression ratio; 
Adjustable image size 


Yes - auto negotiation 


Yes 


Hook up VCR now or 
use LiveWarehouse 
due to come out this 
year 


Yes - snapshot into 
* bmp format 


MCU pending; 
LiveLAN 3.5 will also 
support multicast and 
H.263 


Audio/Video codec 
board required 


u. 


Netscape 

Conference 


No Video 


No Video 


No Video 


No Video 


No Video 


No Video 


No Video 


LU 


Microsoft NetMeeting 


Adjustable video quality 
(changes a 
combination of 
compression and frame 
rate used); Adjustable 
image size 


No 




No 


Yes -snapshot to *.bmp 


MCU pending 




Q 


Intel Business Video 
Conferencing with ProShare 
Technology 


LANDesk Conferencing 
Manager can dynamically 
limit the number of 
conferences as well as the 
bandwidth used in each 
conference based on overall 
network consumption. 
Automatically limiting the 
bandwidth effectively limits 
the frame rate at the client. 


Yes - auto negotiation 
(sharper versus smoother) 


Yes - 200 Kbps 
versus 450 Kbps 


A video recorder for this 
product is in development 


Yes - snapshot into *bmp, 
*.tif. and *. gif formats 


MCU pending 


Intel video capture/audio 
board required 


O 


LBL VIC 


Adjustable frame 
rate; adjustable 
compression by 
selecting new 
encoder; 
adjustable image 
size 


o 

z 


Yes 


o 

z 


o 

Z 






m 


Paradise Simplicity 
H 323 


Adjustable frame 
rate; Adjustable 
compression ratio 


No 


Yes 


o 

z 


No - operator must 
use 3rd party 
snapshot tool, e g., 
Sun Image Tool for 
Unix or Xv for NT 






< 




Dynamic bandwidth 
control 

- Adjustable frame rate 

- Adjustable compression 
ratio 

- Adjustable image size 


Adapt to lowest common 
denominator 


Rate governing 


Save video conference 


Frame grab a video 
image (list file format) 


Other 


Known Issues 
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CM 
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Shared Whiteboards 



— 1 


WhitePines 

CUSeeMe 


o 

CO 


o 

2 


No 


Win95, NT4.0 


(A 

£ 


Yes, via Reflector 
or Multicast 


Captured Window, 
Selected Screen 
Area, JPEG 


i TIFF, JPEG 


Yes 


Yes except no 
arrow, no polygon 


Yes, via Reflector 
only 


Yes 


* 


VocalTec ICP 


1 1 


O 

2 


No 


Win95, NT 
4.0 


(A 

a> 

>- 


Yes, via MCU 


Captured 
window, 
Selected 
screen area, 
JPEG 


None 


Yes, but can't 
select or 
relocate 
annotations 


Yes, Including 
diamond, no 
polygon 


Yes 


o 

2 




Sun ShowMe 


iOZ 


Yes 


No 


No 


S9A 


Yes, via Peer to 
Peer or 
Multicast 


Captured 
Window, 
Selected 
Screen Area, 
Sun Raster 


JPEG 


Yes, but can’t 
select or 
relocate 
annotations 


Yes except no 
arrow (besides 
a stamp), and 
no polygon 


Yes 


S9A 


- 


PictureTel 

LiveLAN 


o 

CO 


1 ° N 


on 


Win95, NT 4.0 
(End of 97) 


(A 

a> 

>- 


Yes, via Peer to 
Peer or MCU 


Captured 
Window, 
Selected Screen 
Area 


None 


«A 

* 


Yes except no 
arrow, no 
polygon 


Yes 


1 


X 


Netscape 

Conference 


CO 

d 


</> 

$ 


S9A 


Win95, NT 4.0 


(A 

f 


No 


Captured 
Window, 
Selected 
Screen Area 
(inside app), 
GIF, JPEG 


JPEG, TIFF 


Yes, but can't 
select or 
relocate 
annotations 


Yes except no 
arrow, no 
polygon 


Yes 


1 S3 A 1 


o 


Microsoft 

NetMeeting 


o 

fsi 


No 


No 


Win95, NT 4.0 


(A 

flj 

>- 


Yes, via Peer to 
Peer or MCU 


Captured 
Window, 
Selected 
Screen Area 


None 


Yes 


Yes except no 
arrow, no 
polygon 


Yes 


$a A 1 


u_ 


LBLWB 


cr> 

in 


1 saA 1 


sa A 1 


No 


L S9 a" ~~| 


Yes, via 
Multicast 


Postscript 


None 


Yes 


Yes, excpet no 
circle or 
polygon 


DES encryption 


1 °N 1 


LU 


Intel Business Video 
Conferencing with 
ProShare 
Technology 


io 1 


o 

2 


I on 


Win95, NT4.0 
(Planned) 


(A 

2 


Yes, via Peer to 
Peer 


Captured Window, 
Selected Screen 
Area 


None 


Yes 


Yes except no arrow, 
no polygon 


Yes 


Yes 
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Habanero 

Whiteboard 


-O 

O 


| S9A 


(A 

45 

>- 


Win95, NT4.0 


(A 

0) 

> 


Yes, via 
Conference 
Server 


JPEG. GIF 


None 


Yes 


Yes, no arrow, 
cirlce, polygon 




sa A 1 


O 


DataBeam 

FarSite 


O 

CO 


1 ° N 1 


ON 


Win95, NT 4.0 


(A 

* 


Yes, via Peer to 
Peer or MCU 


Captured 
Window, 
Selected Screen 
Area, JPEG 


TIFF, JPEG 


Yes 


Yes except no 
arrow, no 
polygon 


Yes 


Yes 


CD 


Paradise Simplicity 
H.323 


p 


Yes (Fall 97) 


Yes (Fall 97) 


Yes (Fall 97) 


(A 

2 


Yes, via Multicast 
or MCU (Fall 97) 


Captured Window, 
Selected Screen 
Area, JPEG, 
Raster, NITF 2.0 
(but uncompressed 
and no metadata) 


JPEG, TIFF, GIF 


Yes, but can't 
select or relocate 
annotations 


Yes except no 
arrow, no polygon 


No 


Yes 


< 




Tool Version 


Solaris 2.5.1 


HP-UX 


IN 


| IP-based 


Multiuser conferencing 
(>2 users) 


Import backdrop formats 
(0 and 24-bit) 

- Captured window 

- Selected screen area 

- JPEG image 

- Raster image 

- NITF image (bring in 
meta data) 

- GIF image 
^Postscript image 


txpon udCKorop image 

and burned in 

annotations 

-JPEG 

-TIFF 

-GIF 

- Postscript 

- NITF (annotations not 
burned in with meta 
data) 


Nondestructive 
annotations during 
session 


Annotation tools for text, 
line, arrow, rectangle, 
circle, oval, polygon, 
freed raw 


Conference participation 
control (private, no 
eavesdropping) (Not 
security) 


iGesturinq/pointinq tool 
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Shared Whiteboards 
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WhitePines 

CUSeeMe 


No, removal of self 
only 


Yes 


Yes 


s 

c 
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m 
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6 

Z 


Captured 
Desktop, TIFF, 
FST, BMP, DIB, 
PCX, TGA, PCT, 
EPS, WPG, WMF, 
DCX 


FST, BMP, DIB, 
PCX. TGA. PCT, 
EPS, WPG, WMF. 
DCX 
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£ 
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o 
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O 
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o 

z 
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Yes 
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Select and delete 


1 j 


* 


VocalTec ICP 


No, removal 
of self only 


Yes 


Yes 


o 

z 


MS Office 
docs and any 
OLE server 
object 


CFR 
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o 
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o 
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Yes, if from 
an OLE server! 
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o 
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O 
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Yes 
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Sun ShowMe 


Yes 


Yes 


No - can only 
save burned-in 
images 
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None 


Sun Raster 
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$ 
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o 
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z 


o 
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o 
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o 
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Yes - bottom 
layer 
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sax 
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o 

z 


I 
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PictureTel 

LiveLAN 


No, removal of 
self only 


Yes 
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WHT 


WHT 
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o 

Z 


o 

z 


o 
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o 

Z 


o 

z 




1 
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$ 
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Netscape 

Conference 


No, removal of 
self only 


o 

Z 
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o 

z 


Captured 
Desktop, TIFF, 
BMP 


BMP 


to 

o 

> 


o 

Z 


O 

z 


o 
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o 

Z 


o 
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o 

z 


o 
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o 
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Microsoft 

NetMeeting 


No, removal of 
self only 


Yes 


Yes 


| No, planned | 


WHT 


WHT 


1 “A J 


o 

Z 


o 

z 


o 
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o 

Z 


o 
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LBLWB 


No, removal of 
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o 
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o 

z 


Text 


o 

z 
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o 

z 


o 
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o 
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o 
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o 
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o 
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o 
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o 

z 


o 

z 


Yes 


ON 


UJ 


Intel Business Video 
Conferencing with 
ProShare 
Technology 


No, removal of self 
only 


Yes 


Yes 


No, planned 


WHT 


WHT 
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o 

Z 


o 
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o 
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in 

0) 
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Yes 


Yes 


in 
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in 
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S0A 


■mi 


Q 
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Whiteboard 


No, removal of 
self only 
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o 

z 


o 

z 


None 


o 

Z 
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? 


o 

Z 


o 
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o 
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o 

Z 


o 

z 


Whiteboard is a 
demo only 


o 

Z 


o 

z 


o 

z 
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delete 


o 

Z 
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DataBeam 

FarSite 


No, removal of 
self only 


Yes 


Yes 


No, planned j 


Captured 
Desktop, TIFF, 
FST, BMP, DIB. 
PCX, TGA, PCT, 
EPS, WPG, 
WMF, DCX 


FST, BMP, DIB, 
PCX, TGA. PCT, 
EPS, WPG, 
WMF. DCX 


in 

® 

>■ 


o 

Z 


No 


o 

Z 


No 


No 


15 

© 


£ 


No 


Yes 


m 

© 

>- 


j 

0 


delete 


to 

0) 

> 


m 


Paradise Simplicity 
H.323 


No, removal of self 
only 


Yes 


No - can only save 
burned-in images 


No, planned 


TIFF, BMP, TARGA 


BMP 


in 


o 

z 


o 

z 


No 


o 

Z 


o 

z 




o 

z 


o 

z 


o 

z 
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to 

J 


S0A 


m 

a> 

> 
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Dynamic 

addition/removal of users 
during session 


Multiple users (>2) 

annotating 

simultaneously 


Persistence of 
whiteboards for use In 
future sessions 


8 

i-' 


Other Import backdrop 
formats (list) 


Other Export backdrop 
formats 


[Multi-color annotations | 


[Functionality plug-ins 


Import custom symbols 
for annotations 


Overlay vector graphics 
(VPF, CGM) on raster 
backgrounds 


symbols on imported 
maps 


Attributed annotations: 
user, date, comments 


Known Issues 


|De-synchronize 


Can lock whiteboard 
contents 


(Highlighter 


iFilled rectangle option | 


| Filled circle/oval option | 


I Eraser 


IZoom capability 
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Shared Whiteboards 



— 1 


WhitePines 

CUSeeMe 


Yes - but only 
from one page to 
another within the 
whiteboard; not 
within a page and 
not to outside 
applications 


Yes 


(A 

o> 

> 


1 Uh 1 


Yes 


Uses Databeam’s 
FarSite for the 
Whiteboard 


* 


VocalTec ICP 


No. but can 
copy and 
paste OLE 
objects onto 
and within 
whiteboard 


o 

2 


(A 

<D 

> 


1 !?A 1 


o 

2 




-> 


Sun ShowMe 


o 

2 


O 

2 


(A 

2 


o 

2 


Yes 


Sun has T.120 
product in the 
works 


- 


PictureTel 

LiveLAN 


Yes • both from 
within a page and 
from one page to 
another within the 
whiteboard as 
well as to outside 
applications 


Yes 


s®A 


S9 A | 


Yes 


Uses same core 
software as MS 
NetMeeting for 
the Whiteboard. 
LiveLAN 3.5 will 
run under NT4.0 
and will use the 
MS NetMeeting 
application that 
comes bundled 
with NT4 0 for its 
data conferencing 
tool 


X 


Netscape 

Conference 


Yes - can 
select 
annotation 
region and 
paste it as a 
bitmap; Can 
also paste 
text/graphics 
from other 
applications as 
bitmaps 


o 

2 


sax 


o 

2 


Only two can 
participate in a 
whiteboard 
session 


Original 

Whiteboard 

Software 


o 


Microsoft 

NetMeeting 


Yes - both from 
within a page 
and from one 
page to another 
within the 
whiteboard as 
well as to 
outside 
applications 


1 !!* 


S ®A 


sa A 1 


Yes 


Original 

Whiteboard 

Software 


LL 


LBLWB 


Yes 


!?* 


(A 

£ 


IA 

0> 

> 


Yes 




UJ 


Intel Business Video 
Conferencing with 
ProShare 
Technology 


Yes - both from 
within a page and 
from one page to 
another within the 
whiteboard as well 
as to outside 
applications 


Yes 


S9A 


(A 

* 


Yes 


Uses MS 

NetMeeting for the 
Whiteboard 


O 


Habanero 

Whiteboard 


o 

2 


Yes 


o 

2 


o 

2 


Yes 




o 


DataBeam 

FarSite 


Yes - but only 
from one page to 
another within 
the whiteboard, 
not within a page 
and not to 
outside 
applications 


IA 

£ 


1 S9A ! 


*®A I 


Yes 


Original 

Whiteboard 

Software 


CD 


Paradise Simplicity 
H.323 


o 

2 


o 

2 


O 

2 


o 

2 


Yes 


Original 

Whiteboard 

Software 


< 




Copy and paste 
annotations 




[contents 


[Multi-page 


Conference participants 
idantified 


Notes 




- 


CO 


in 

CO 


<o 

CO 


CO 


CO 

CO 
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APPENDIX C: BANDWIDTH REQUIREMENTS MATRIX 



The following matrix was put together to consolidate bandwidth requirements for 
collaborative planning or for collaboration tools encountered by the author during her 
research. The sources are listed in the first column. 
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Bandwidth Requirements. 



APPENDIX D: EXTEND MODEL STRUCTURES 



The model structures are presented as printouts obtained from the Extend displays. 
Many levels of hierarchy can be built into a model and several pages are used to shown 
each level of the node and router structures, starting at the top levels and working down 
into the details of specific blocks. 

The node structure shown is that of Node 1 which sends out audio, video, and 
whiteboard messages with annotations. This basic structure was copied to represent the 
number of nodes in the scenario, from two to nine. 

The router structure shown is that of the Multicast router with the “replicator” 
block. A Unicast router is achieved by disconnecting the replicator block in the model. 
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Node Structure 
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Node structure.MOX - 




|315](1) filter 
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Node structure.MOX • 
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Node structure.MOX • 








|1221| four type sorter 
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Node structure. MOX 
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Router Structure.MOX - 









Replicator: Determines which node sent the message then makes copies for all destinations. 







Router Structure.MOX - 









Make Copies: For a message from a specific node (in this case Node 1), replicate for distribution 
to other nodes in the subnet (node 2 and 3), and to other Routers (Routers 20 and 
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Router Structure.MOX - 
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Router Structure.MOX - 









APPENDIX E: EXTEND MODEL RUNS 



The following matrices show the various combinations of parameters that were 
used and the resulting model runs that were executed. 
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Baseline Runs - 3 nodes 



Run Number 


session type 


# nodes 


Delivery 


Bandwidth 


111 


text chat - high 


3 


unicast 


384 kbps 


112 


audio - 1 4.4 kbps 


3 


unicast 


384 kbps 


113 


audio - 64 kbps 


3 


unicast 


384 kbps 


114 


video - low 4 fps + 14.4 kbps audio 


3 


unicast 


384 kbps 


115 


video - low 4 fps + 64 kbps audio 


3 


unicast 


384 kbps 


116 


video - high 1 5 fps + 14.4 kbps audio 


3 


unicast 


384 kbps 


117 


video - high 15 fps + 64 kbps audio 


3 


unicast 


384 kbps 


118 


wb + 14.4 kbps audio 


3 


unicast 


384 kbps 


119 


wb + 64 kbps audio 


3 


unicast 


384 kbps 


120 


wb + 4 fps video + 14.4 kbps audio 


3 


unicast 


384 kbps 


121 


wb + 4 fps video + 64 kbps audio 


3 


unicast 


384 kbps 


122 


wb + 1 5 fps video + 1 4.4 audio 


3 


unicast 


384 kbps 


123 


wb + 1 5 fps video + 64 kbps audio 


3 


unicast 


384 kbps 






















311 


text chat - high 


3 


multicast 


384 kbps 


312 


audio - 14.4 kbps 


3 


multicast 


384 kbps 


313 


audio - 64 kbps 


3 


multicast 


384 kbps 


314 


video - low 4 fps + 1 4.4 kbps audio 


3 


multicast 


384 kbps 


315 


video - low 4 fps + 64 kbps audio 


3 


multicast 


384 kbps 


316 


video - high 15 fps + 14.4 kbps audio 


3 


multicast 


384 kbps 


317 


video - high 15 fps + 64 kbps audio 


3 


multicast 


384 kbps 


318 


wb + 14.4 kbps audio 


3 


multicast 


384 kbps 


319 


wb + 64 kbps audio 


3 


multicast 


384 kbps 


320 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


384 kbps 


321 


wb + 4 fps video + 64 kbps audio 


3 


multicast 


384 kbps 


322 


wb + 15 fps video + 14.4 audio 


3 


multicast 


384 kbps 


323 


wb + 1 5 fps video + 64 kbps audio 


3 


multicast 


384 kbps 






















511 


text chat - high 


3 


unicast 


128 kbps 


512 


audio - 14.4 kbps 


3 


unicast 


128 kbps 


513 


audio - 64 kbps 


3 


unicast 


1 28 kbps 


514 


video - low 4 fps + 14.4 kbps audio 


3 


unicast 


128 kbps 


515 


video - low 4 fps + 64 kbps audio 


3 


unicast 


128 kbps 


516 


video - high 15 fps + 14.4 kbps audio 


3 


unicast 


1 28 kbps 


517 


video - high 15 fps + 64 kbps audio 


3 


unicast 


128 kbps 


518 


wb + 1 4.4 kbps audio 


3 


unicast 


1 28 kbps 


519 


wb + 64 kbps audio 


3 


unicast 


128 kbps 


520 


wb + 4 fps video + 1 4.4 kbps audio 


3 


unicast 


128 kbps 


521 


wb + 4 fps video + 64 kbps audio 


3 


unicast 


1 28 kbps 


522 


wb + 1 5 fps video + 1 4.4 audio 


3 


unicast 


1 28 kbps 


523 


wb + 1 5 fps video + 64 kbps audio 


3 


unicast 


128 kbps 






















711 


text chat - high 


3 


multicast 


128 kbps 


712 


audio - 1 4.4 kbps 


3 


multicast 


1 28 kbps 


713 


audio - 64 kbps 


3 


multicast 


128 kbps 


714 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


128 kbps 


715 


video - low 4 fps + 64 kbps audio 


3 


multicast 


128 kbps 


716 


video - high 15 fps + 14.4 kbps audio 


3 


multicast 


128 kbps 


717 


video - high 1 5 fps + 64 kbps audio 


3 


multicast 


1 28 kbps 


718 


wb + 14.4 kbps audio 


3 


multicast 


1 28 kbps 


719 


wb + 64 kbps audio 


3 


multicast 


1 28 kbps 


720 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


1 28 kbps 


721 


wb + 4 fps video + 64 kbps audio 


3 


multicast 


1 28 kbps 


722 


wb + 1 5 fps video + 1 4.4 audio 


3 


multicast 


128 kbps 


723 


wb + 1 5 fps video + 64 kbps audio 


3 


multicast 


1 28 kbps 
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Baseline Runs - 9 Nodes 



Run Number 


session type 


# nodes 


Delivery 


Bandwidth 


211 


text chat - high 


9 


unicast 


1 28 kbps 


212 


audio - 14.4 kbps 


9 


unicast 


128 kbps 


213 


audio - 64 kbps 


9 


unicast 


128 kbps 


214 


video - low 4 fps + 14.4 kbps audio 


9 


unicast 


128 kbps 


215 


video - low 4 fps + 64 kbps audio 


9 


unicast 


128 kbps 


216 


video - high 15 fps + 14.4 kbps audio 


9 


unicast 


128 kbps 


217 


video - high 15 fps + 64 kbps audio 


9 


unicast 


128 kbps 


218 


wb + 14.4 audio 


9 


unicast 


1 28 kbps 


219 


wb + 64 kbps audio 


9 


unicast 


128 kbps 


220 


wb + 4 fps video + 14.4 kbps audio 


9 


unicast 


128 kbps 


221 


wb + 4 fps video + 64 kbps audio 


9 


unicast 


1 28 kbps 


222 


wb + 15 fps video + 1 4.4 audio 


9 


unicast 


128 kbps 


223 


wb + 1 5 fps video + 64 kbps audio 


9 


unicast 


128 kbps 






















411 


text chat - high 


9 


multicast 


128 kbps 


412 


audio - 14.4 kbps 


9 


multicast 


128 kbps 


413 


audio - 64 kbps 


9 


multicast 


128 kbps 


414 


video - low 4 fps + 14.4 kbps audio 


9 


multicast 


128 kbps 


415 


video - low 4 fps + 64 kbps audio 


9 


multicast 


128 kbps 


416 


video - high 15 fps + 14.4 kbps audio 


9 


multicast 


1 28 kbps 


417 


video - high 15 fps + 64 kbps audio 


9 


multicast 


128 kbps 


418 


wb + 14.4 kbps audio 


9 


multicast 


128 kbps 


419 


wb + 64 kbps audio 


9 


multicast 


1 28 kbps 


420 


wb + 4 fps video + 14.4 kbps audio 


9 


multicast 


1 28 kbps 


421 


wb + 4 fps video + 64 kbps audio 


9 


multicast 


128 kbps 


422 


wb + 1 5 fps video + 14.4 audio 


9 


multicast 


128 kbps 


423 


wb + 1 5 fps video + 64 kbps audio 


9 


multicast 


1 28 kbps 






















611 


text chat - high 


9 


unicast 


384 kbps 


612 


audio - 14.4 kbps 


9 


unicast 


384 kbps 


613 


audio - 64 kbps 


9 


unicast 


384 kbps 


614 


video - low 4 fps + 1 4.4 kbps audio 


9 


unicast 


384 kbps 


615 


video - low 4 fps + 64 kbps audio 


9 


unicast 


384 kbps 


616 


video - high 15 fps + 14.4 kbps audio 


9 


unicast 


384 kbps 


617 


video - high 1 5 fps + 64 kbps audio 


9 


unicast 


384 kbps 


618 


wb + 14.4 audio 


9 


unicast 


384 kbps 


619 


wb + 64 kbps audio 


9 


unicast 


384 kbps 


620 


wb + 4 fps video + 14.4 kbps audio 


9 


unicast 


384 kbps 


621 


wb + 4 fps video + 64 kbps audio 


9 


unicast 


384 kbps 


622 


wb + 15 fps video + 14.4 audio 


9 


unicast 


384 kbps 


623 


wb + 1 5 fps video + 64 kbps audio 


9 


unicast 


384 kbps 






















811 


text chat - high 


9 


multicast 


384 kbps 


812 


audio - 14.4 kbps 


9 


multicast 


384 kbps 


813 


audio - 64 kbps 


9 


multicast 


384 kbps 


814 


video - low 4 fps + 14.4 kbps audio 


9 


multicast 


384 kbps 


815 


video - low 4 fps + 64 kbps audio 


9 


multicast 


384 kbps 


816 


video - high 15 fps + 1 4.4 kbps audio 


9 


multicast 


384 kbps 


817 


video - high 15 fps + 64 kbps audio 


9 


multicast 


384 kbps 


818 


wb + 14.4 kbps audio 


9 


multicast 


384 kbps 


819 


wb + 64 kbps audio 


9 


multicast 


384 kbps 


820 


wb + 4 fps video + 1 4.4 kbps audio 


9 


multicast 


384 kbps 


821 


wb + 4 fps video + 64 kbps audio 


9 


multicast 


384 kbps 


822 


wb + 1 5 fps video + 1 4.4 audio 


9 


multicast 


384 kbps 


823 


wb + 1 5 fps video + 64 kbps audio 


9 


multicast 


384 kbps 
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Focused Runs 













Run Number 


session type 


# nodes 


Delivery 


Bandwidth 












2 NODES 










14 


video - low 4 fps + 14.4 kbps audio 


2 


unicast 


128 kbps 


14b 


video - low 4 fps + 14.4 kbps audio 


2 


unicast 


384 kbps 


14c 


video - low 4 fps + 14.4 kbps audio 


2 


unicast 


256 kbps 












18 


wb + 14.4 kbps audio 


2 


unicast 


128 kbps 


18b 


wb + 14.4 kbps audio 


2 


unicast 


384 kbps 


18c 


wb + 14.4 kbps audio 


2 


unicast 


256 kbps 












20 


wb + 4 fps video + 14.4 kbps audio 


2 


unicast 


128 kbps 


20b 


wb + 4 fps video + 14.4 kbps audio 


2 


unicast 


384 kbps 


20c 


wb + 4 fps video + 14.4 kbps audio 


2 


unicast 


256 kbps 












3 NODES 










514 


video - low 4 fps + 14.4 kbps audio 


3 


unicast 


128 kbps 


114 


video - low 4 fps + 14.4 kbps audio 


3 


unicast 


384 kbps 


1111 


video - low 4 fps + 14.4 kbps audio 


3 


unicast 


256 kbps 












518 


wb + 14.4 kbps audio 


3 


unicast 


128 kbps 


118 


wb + 14.4 kbps audio 


3 


unicast 


384 kbps 


1115 


wb + 14.4 kbps audio 


3 


unicast 


256 kbps 












520 


wb + 4 fps video + 14.4 kbps audio 


3 


unicast 


128 kbps 


120 


wb + 4 fps video + 14.4 kbps audio 


3 


unicast 


384 kbps 


1119 


wb + 4 fps video + 14.4 kbps audio 


3 


unicast 


256 kbps 












714 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


128 kbps 


314 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


384 kbps 


1113 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


256 kbps 












718 


wb + 14.4 kbps audio 


3 


multicast 


128 kbps 


318 


wb + 14.4 kbps audio 


3 


multicast 


384 kbps 


1117 


wb + 14.4 kbps audio 


3 


multicast 


256 kbps 












720 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


128 kbps 


320 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


384 kbps 


1121 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


256 kbps 
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Focused Runs 



6 NODES 










64 


video - low 4 fps + 14.4 kbps audio 


6 


unicast 


1 28 kbps 


64b 


video - low 4 fps + 14.4 kbps audio 


6 


unicast 


384 kbps 


64c 


video - low 4 fps + 14.4 kbps audio 


6 


unicast 


256 kbps 












68 


wb + 14.4 kbps audio 


6 


unicast 


128 kbps 


68b 


wb + 14.4 kbps audio 


6 


unicast 


384 kbps 


68c 


wb + 14.4 kbps audio 


6 


unicast 


256 kbps 












70 


wb + 4 fps video + 14.4 kbps audio 


6 


unicast 


128 kbps 


70b 


wb + 4 fps video + 14.4 kbps audio 


6 


unicast 


384 kbps 


70c 


wb + 4 fps video + 14.4 kbps audio 


6 


unicast 


256 kbps 












6014 


video - low 4 fps + 14.4 kbps audio 


6 


multicast 


128 kbps 


6014b 


video - low 4 fps + 14.4 kbps audio 


6 


multicast 


384 kbps 


64c 


video - low 4 fps + 14.4 kbps audio 


6 


multicast 


256 kbps 












6018 


wb + 14.4 kbps audio 


6 


multicast 


128 kbps 


6018b 


wb + 14.4 kbps audio 


6 


multicast 


384 kbps 


6018c 


wb + 14.4 kbps audio 


6 


multicast 


256 kbps 












6020 


wb + 4 fps video + 14.4 kbps audio 


6 


multicast 


128 kbps 


6020b 


wb + 4 fps video + 14.4 kbps audio 


6 


multicast 


384 kbps 


6020c 


wb + 4 fps video + 14.4 kbps audio 


6 


multicast 


256 kbps 












9 NODES 










214 


video - low 4 fps + 14.4 kbps audio 


9 


unicast 


128 kbps 


614 


video - low 4 fps + 14.4 kbps audio 


9 


unicast 


384 kbps 


1112 


video - low 4 fps + 14.4 kbps audio 


9 


unicast 


256 kbps 












218 


wb + 14.4 kbps audio 


9 


unicast 


128 kbps 


618 


wb + 14.4 kbps audio 


9 


unicast 


384 kbps 


1116 


wb + 14.4 kbps audio 


9 


unicast 


256 kbps 












220 


wb + 4 fps video + 14.4 kbps audio 


9 


unicast 


128 kbps 


620 


wb + 4 fps video + 14.4 kbps audio 


9 


unicast 


384 kbps 


1120 


wb + 4 fps video + 14.4 kbps audio 


9 


unicast 


256 kbps 












414 


video - low 4 fps + 14.4 kbps audio 


9 


multicast 


128 kbps 


814 


video - low 4 fps + 14.4 kbps audio 


9 


multicast 


384 kbps 


1114 


video - low 4 fps + 14.4 kbps audio 


9 


multicast 


256 kbps 












418 


wb + 14.4 kbps audio 


9 


multicast 


128 kbps 


818 


wb + 14.4 kbps audio 


9 


multicast 


384 kbps 


1118 


wb + 14.4 kbps audio 


9 


multicast 


256 kbps 












420 


wb + 4 fps video + 14.4 kbps audio 


9 


multicast 


128 kbps 


820 


wb + 4 fps video + 14.4 kbps audio 


9 


multicast 


384 kbps 


1122 


wb + 4 fps video + 14.4 kbps audio 


9 


multicast 


256 kbps 
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Special Runs 



Point to Point Scenario 








Run Number 


session type 


# nodes 


Delivery 


Bandwidth 












14 


video - low 4 fps + 14.4 kbps audio 


2 


unicast 


128 kbps 


14b 


video - low 4 fps + 14.4 kbps audio 


2 


unicast 


384 kbps 


14c 


video - low 4 fps + 14.4 kbps audio 


2 


unicast 


256 kbps 


14d 


video - low 4 fps + 14.4 kbps audio 


2 


unicast 


64 kbps 












18 


wb + 14.4 kbps audio 


2 


unicast 


1 28 kbps 


18b 


wb + 14.4 kbps audio 


2 


unicast 


384 kbps 


18c 


wb + 14.4 kbps audio 


2 


unicast 


256 kbps 


18d 


wb + 14.4 kbps audio 


2 


unicast 


64 kbps 












20 


wb + 4 fps video + 14.4 kbps audio 


2 


unicast 


128 kbps 


20b 


wb + 4 fps video + 14.4 kbps audio 


2 


unicast 


384 kbps 


20c 


wb + 4 fps video + 14.4 kbps audio 


2 


unicast 


256 kbps 


20d 


wb + 4 fps video + 14.4 kbps audio 


2 


unicast 


64 kbps 






















Satellite as Multicast Router 








Run Number 


session type 


# nodes 


Delivery 


Bandwidth 


1023 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


128 


1023b 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


256 


1024 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


384 












1025 


wb + 14.4 kbps audio 


3 


multicast 


128 


1025b 


wb + 14.4 kbps audio 


~3 


multicast 


256 


1026 


wb + 14.4 kbps audio 


3 


multicast 


384 












1031 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


128 


1031b 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


256 


1031c 


wb + 4 fps video + 14.4 kbps audio 


~3 


multicast 


384 












Satellite Ashore 








1027 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


128 


1027b 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


256 


1028 


video - low 4 fps + 14.4 kbps audio 


3 


multicast 


384 












1029 


wb + 14.4 kbps audio 


3 


multicast 


128 


1029b 


wb + 14.4 kbps audio 


3 


multicast 


256 


1030 


wb + 14.4 kbps audio 


3 


multicast 


384 












1032 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


128 


1032b 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


256 


1032c 


wb + 4 fps video + 14.4 kbps audio 


3 


multicast 


384 
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APPENDIX F: EXTEND MODEL RESULTS 



The following spreadsheets contain the data that was collected from the Extend 
model runs. Additional rearrangements were performed in order to generate the charts 
presented in Chapter V. 
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UNICAST, 128 kbps 
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UNICAST, 128 kbps 
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1 2, 3, 6, 9 Node Runs 
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(Video (4 fps) + Audio (14.4 kbps) 


2 node 
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|6 node | 
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Focused Runs 
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1 Unicast 256 




[Video (4 fps) + Audio (14.4 kbps) 


2 node 
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Focused Runs 
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[Unicast 384 


| Video (4 fps) + Audio (14.4 kbps) 
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Focused Runs 
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1 Multicast 128 


1 Video (4 fps) + Audio (14.4 kbps) 


2 node 


3 node 


6 node 
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|2 node Audio (Runs 914, 918, 920) | 
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Focused Runs 
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| Multicast 256 


|Vldeo (4 fps) + Audio (14.4 kbps) 
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Focused Runs 
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I Multicast 384 


| Video (4 fps) + Audio (14.4 kbps) 


2 node 


3 node 


|6 node 


9 node 




|2 node Audio 
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Special Runs 



Satellite as multicast router 
















































Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 














3 node 


0.784333 


0.941 


0.944 


0.829 


0.715 


0.719 


0.558 


















3 node Audio 




0.941 


0.944 


0.829 








3 node Video 




0.715 


0.719 


0.558 
























Wb + Audio (14.4 kbps) 


Avg Delay 














3 node Audio 


0.872667 


1.097 


0.727 


0.794 








3 node Wb 


9.193 


9.193 


9.193 


























Wb + Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 














3 node 


1.820333 


1.669 


2.107 


1.79 


1.978 


1.891 


1.487 


3 node Wb 
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9.193 


9.193 


























































Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 














3 node 


0.589333 


0.738 


0.738 
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0.52 


0.521 
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3 node Audio 
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0.738 
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3 node Video 
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Wb + Audio (14.4 kbps) 
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3 node Audio 
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0.43 
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4.716 


4.716 


























Wb + Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 
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3 node Wb 


4.7985 
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******* 384 kbps 
















Video (4 fps) + Audio (14.4 kbps) 
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0.539667 
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0.466 


0.468 


0.347 
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0.692 


0.693 


0.572 








3 node Video 
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Wb + Audio (14.4 kbps) 


Avg Delay 














3 node Audio 


0.406 


0.493 


0.373 


0.352 








3 node Wb 


3.23 


3.23 


3.23 
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Special Runs 



















Multicast router ashore 
















































Video (4 fps) + Audio (14.4 kbps) 
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1.649 


1.539 
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1.281 
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Avg Delay 














3 node 


9.054833 


8.75 


9.073 


9.584 


9.175 


8.639 


9.108 


3 node Wb 


9.746 


9.746 


9.746 










































Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 














3 node 


1.044833 


1.338 


1.338 


1.192 


0.879 


0.881 


0.641 


















3 node Audio 




1.338 


1.338 


1.192 








3 node Video 




0.879 


0.881 


0.641 
























Wb + Audio (14.4 kbps) 


Avg Delay 














3 node Audio 


0.743 


0.905 


0.656 


0.668 








3 node Wb 


5.016 


5.016 


5.016 


























Wb + Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 














3 node 


7.285167 


6.873 


7.408 


7.764 


7.353 


6.938 


7.375 


3 node Wb 


5.039 


5.039 


5.039 


























******* 384 kbps 
















Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 














3 node 


0.992 


1.292 


1.293 


1.128 


0.824 


0.828 


0.587 


















3 node Audio 




1.292 


1.293 


1.128 








3 node Video 




0.824 


0.828 


0.587 
























Wb + Audio (14.4 kbps) 


Avg Delay 














3 node Audio 


0.660667 


0.744 


0.655 


0.583 








3 node Wb 


3.529 


3.529 


3.529 


























Wb + Video (4 fps) + Audio (14.4 kbps) 


Avg Delay 














3 node 


6.745 


6.534 


7.059 


6.827 


6.955 


6.666 


6.429 


3 node Wb 


3.582 


3.582 


3.582 
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